[American Institute of Aeronautics and Astronautics Infotech@Aerospace 2011 - St. Louis, Missouri...

American Institute of Aeronautics and Astronautics

1

System Architecture for the CUSat Spacecraft: a Flight Experiment in GPS-Carrier-Phase Differential Navigation

and Control

Nao Murakami1 and Mason Peck2 Cornell University, Ithaca, NY, 14853

Cornell University’s CUSat is the winner of the University Nanosat-4 Program. It is scheduled to launch on a SpaceX Falcon 9 in March 2012. The CUSat satellite system consists of two functionally identical spacecraft: Top and Bottom. The two launch together and separate from each other in orbit. CUSat’s primary mission is an experiment in closed-loop navigation with carrier-phase differential GPS (CDGPS), which provides centimeter-accurate knowledge of relative position and absolute attitude knowledge within 1 degree. After Top and Bottom separate from one another, both satellites will perform autonomous, GPS only relative navigation with one satellite capturing the image of the other. These images will be combined on the ground to reconstruct a 3D model of one of the satellites with sufficient resolution to verify the accuracy of CDGPS. CUSat’s mission will be the first spacecraft to demonstrate GPS only, closed-loop guidance, navigation, and control.

I. Introduction ARRIER Phase Differential GPS (CDGPS) promises to enable high-precision relative navigation for earth satellites. The relative-position estimate is based on the phase of the incoming carrier as the signal passes two

or more spatially distinct antennas. Tracking that relative phase and resolving the integer number of wavelengths between antennas provides relative-position knowledge to within a centimeter in LEO. Recent work by Psiaki1 and Montenbruck2, to name a few, has advanced the state of the art to the point where CDGPS is ready for experimental validation in flight. CUSat serves as that first flight.

Gershman et al. summarize Psiaki’s CDGPS algorithm3, which is implemented on CUSat. CUSat takes the experiment beyond the data-collection objectives of the successful FASTRAC4 experiment by using realtime CDGPS measurements for simultaneous closed-loop control of attitude and relative orbital motion. It does so by demonstrating cooporative, in-orbit inspection: the two satellites share CDGPS data via a cross-link to enable close-proximity navigation and to provide targeting for on-board cameras. CUSat serves as the first nanosatellite capable of in-orbit inspection, and as such it verifies that CDGPS represents a low-cost, low-power solution for high precision.5

CUSat consists of a pair of spin-stabilized spacecraft. Its mission begins with the two satellites in a stacked configuration and with no power in their batteries. After the launch vehicle reaches the separation altitude, CUSat separates from the launch vehicle using a Planetary Systems Corporation Lightband, which imparts a 4-6 deg/sec spin about the stack’s axis of symmetry (its Z or yaw axis), which is its axis of minimum inertia. With no fluids and a 100 Hz first structural mode, the stack experiences very little nutation growth during this mission phase. After launch-vehicle separation, CUSat begins to charge its batteries. Functional checkout of CUSat follows, and the on-board estimator on Top begins to use CDGPS vectors to determine the attitude kinematics of the stack. Nutation control eliminates transverse rates, and Top and Bottom separate from each other using a second Lightband. The individual angular velocities are roughly those of the stack before this separation event. At this point the two spacecraft are in an indefinitely stable, maximum-axis spin. Following spacecraft separation, Top and Bottom each undergo a second functional checkout. An RF crosslink communication is established, and CDGPS data is shared between Top and Bottom. This CDGPS data is downlinked to the Mission Control Center (MCC) at Cornell University through UHF ground stations, which will include one Mount Pleasant in Ithaca, NY and another on 1 Masters Student, Cornell University Mechanical and Aerospace Engineering, Ithaca, NY 14853. Student Member AIAA. 2 Associate Professor, Cornell University Mechanical and Aerospace Engineering, Ithaca, NY. Member AIAA

C

Infotech@Aerospace 201129 - 31 March 2011, St. Louis, Missouri

AIAA 2011-1629

Copyright © 2011 by Nao Murakami and Mason Peck. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.


2

Kwajalein Atoll, in the Marshall Islands. One satellite then captures images of the other with one of the two COTS Adimec 2000 cameras (four in the CUSat system). This image data is then downlinked to the MCC to be combined to generate a 3D shape-from-image model of one of the satellites with sufficient resolution to verify the accuracy of CDGPS.

Figure 1. The Two CUSat Spacecraft Stacked in Their Launch Configuration

CUSat weighs 52kg and fits within a 50cm wide, 50cm high cylindrical envelope, meeting University

Nanosatellite Program 4 (UNP-4) requirements that ensure compatibility with the Evolved Expendable Launch Vehicle Secondary Payload Adapter (ESPA). The system is fully single-fault tolerant in meeting its mission objectives thanks to functional redundancy and its ability to reroute data and functional flow among the two spacecrafts’ subsystems. Each CUSat spacecraft’s flight computer can be independently rebooted via commands from the ground through the telemetry and command subsystem, and each flight computer can be partially or completely reprogrammed if necessary. These features are meant to make CUSat robust to failures and unforeseen errors. Figure 1 shows CUSat in its stacked configuration.

Top and Bottom provide roughly 23W to their respective bus and payload subsystems through body-mounted solar panels. Each is also equipped with three CDGPS receivers. An on-board Extended Kalman Filter uses GPS pseudorange and carrier-phase data from these multiple antennas to provide 1° accurate inertial attitude knowledge, better than 1° accurate relative-attitude knowledge, and 0.1°/sec accurate inertial angular velocity. CUSat’s six degree-of-freedom guidance and control uses only GPS, no other sensors. The actuators on each spacecraft include a three-axis reaction-wheel system donated by IntelliTech Microsystems, Inc (IMI) and eight Pulsed-Plasma Thrusters (PPTs) based on those of the DAWGSTAR satellite6. The IMI wheels provide torque up to 0.635 mNm and angular momentum up to 2 mNms, used for nutation control. Each PPT provides an impulse of 60 µNs, and a single thruster per satellite can be fired approximately every 4 seconds.

Figure 2 shows an internal view of either Top or Bottom. Both have identical structure, hardware, and software, including a Lightband ring on the top. This extra ring is superfluous in the stacked configuration but allows either satellite to take the top position and ensures near-identical mass properties to reduce differences in orbit perturbations. As a secondary payload, CUSat cannot delay the launch. So, if a pre-launch failure in Top would prevent it from performing the initial attitude acquitision, bottom can replace it with no impact to the launch campaign. In their stacked configuration, one is clocked 180° from the other to cancel nearly the systemic mass-center offset, ensuring that the stack meets related launch-vehicle requirements.


3

The CUSat satellite project team extensively utilizes Configuration Management and Quality Assurance (CM&QA) procedures to manage documents, hardware, and software. CUSat team members use Sharepoint to create and revise documents and purchase orders. A Subversion repository stores all code written for CUSat, and access is granted only to those working on software. The hardware is classified as either “flight” or “non-flight.” Non-flight hardware is stored separately from flight hardware and is treated like any other hardware for daily use. Flight hardware is treated differently. All of the flight hardware purchased from the vendor is associated with the following: manufacturer billing receipts or invoices, manufacturer’s certificate of compliance (CoC), material test reports, and lot test data. The single exception to this rule is electronic components, which are conformal coated before flight. Flight hardware is stored in locked cabinets, the keys for which are given to selected members of the team. Each flight-hardware component is kept in electrostatic discharge (ESD) safe clean bags, allowing for safe storage and transportation between clean room and storage cabinets. A Certification Log that must be logged for each event that the flight hardware undergoes accompanies each piece of flight hardware.

After winning the UNP-4 Flight Competition Review (FCR) in 2007, CUSat team completed the fabrication and assembly of the satellites. The CUSat team held Red Team Reviews—consisting of a day-long evaluations by senior technologists from industry—prior to key sponsor reviews, such as PDR and CDR. The hardware was delivered with a reduced-scope subset of the flight software in spring of 2008 as part of the Operationally Responsive Space (ORS) Jumpstart mission. CUSat completed its environmental testing and was to have flown on the third Falcon 1 attempt from Kwajalein. Not long before launch, ORS manifested a different spacecraft, and CUSat’s first launch effort stood down.7 A second launch opportunity arose in 2009 for a launch in 2010, for which CUSat again underwent environmental testing. Once again, CUSat was not ultimately manifested. As of early 2011, CUSat is manifested for launch in March 2012 on the SpaceX Falcon 9. The CUSat team is running mission rehearsals in preparation for this launch.

II. GPS Carrier-Phase Differential Navigation and Control

A. Attitude Determination, Control and Navigation Software Overview CUSat’s Attitude Determination, Control, and Navigation Subsystem (ADCNS) is responsible for all high-level

decisionmaking on the spacecraft, which establishes the power state. These high-level activities include turning on hardware, running navigation algorithms that track the attitude and orbit of the spacecraft, and setting the software mode. Figure 3 shows a block diagram outlining the highest level of the ADCNS software architecture.

Figure 2. Internal View of One of the Two CUSat Spacecraft

Solar Panel

Ham Radio Boxes

IMI

Electronics Backplane

Battery Box

Camera

Camera

PPT

Power Processing Unit Enclosure


4

KFATT Attitude Control Position Control Fault Detection

MOMS

Figure 3. ADCNS Software Structure

The Mission Operations Management System (MOMS) passes information to the lower level ADCNS

components. The lower-level software algorithms do not directly issue commands to the flight hardware; instead, they pass commands through MOMS (e.g. reaction wheel torque from the attitude controller), and MOMS may issue the command, depending on the mode and power status of the spacecraft. MOMS also manages the spacecraft modes, power sources, and mission execution. The modes are determined by the mission timeline and the corresponding hardware and software components that are enabled during that phase of the mission. MOMS power management takes into account eclipses and battery charging by switching off non-critical hardware when necessary.

CUSat’s Kalman Filter for Attitude Estimation (KFATT) processes CDGPS measurements to estimate spacecraft attitude and angular velocity. KFATT propagates the attitude when CDGPS measurements are unavailable. The KFATT algorithm is enabled by MOMS. KFATT stores its estimates of the attitude state in a global memory structure along with information about the error so that the validity of the estimates can be determined. This data can be read by MOMS and passed through to the various feedback-control algorithms. One such algorithm is the wheels-only nutation control, which damps transverse angular velocity. The other, the position controller, uses wheels and thrusters simultaneously to maintain relative orbital elements and to match their spin angular momentum vectors during normal mode.

B. KFATT Development In CUSat ADCNS, the KFATT extended Kalman filter estimates the spacecraft attitude state vector through a

nonlinear least-squares regressive filter that estimates spacecraft attitude, rate, and disturbance torques given baseline CDGPS vectors. KFATT is initialized with an attitude estimate calculated by the ESOQ8 algorithm. At the next time step, if at least one CDGPS measurement is available, the estimate at the time of the CDGPS measurement is refined based on both the estimate calculated at the previous time and the new information provided by the CDGPS measurements. This procedure is recursively repeated at each time step where CDGPS measurements are available. For time steps where CDGPS measurements are not available and the filter has converged, KFATT propagates the state estimate. For time steps where CDGPS measurements are not available and the filter has not converged, KFATT does not propagate the state estimate; instead, it starts recursive filtering upon receipt of the next available CDGPS measurements.

Before KFATT was converted from the MATLAB development environement into C/C++ flight code, extensive simulations via a MATLAB/Simulink model were performed to tune the Kalman filter. Figure 4 shows the data flow in this model. Tuning of the Kalman filter entails choosing the optimal values for the process noise and measurement noise covariance constants, as well as the initial covariances for the attitude quaternion, rates, and disturbance torques.


5

Figure 4. Physical Process Block of the Simulator

Different testing scenarios were developed to best tune the filter, including steady-state performance given 1-3

CDGPS measurements available to KFATT, attitude estimation with uncertainty in the spacecraft inertia, and loss of all CDGPS measurements. The number of CDGPS measurements made available to KFATT is chosen by modifying the value of the constant block titled ‘CDGPS Measurements’ in the Physical Process block of the simulator. The ‘CDGPS Measurements’ block is shown in the lower right corner in Fig. 4.

C. KFATT Simulation Table 1 summarizes the results generated during KFATT simulations, each of which used a different number of

CDGPS vector measurements. Detailed results and plots that were produced during simulations to decide on the covariance constants are included in the Appendix.

Table 1. Error analysis for the 1, 2, and 3 CDGPS measurement simulations

Attitude Error [deg]

Error in Rate about x [deg/s]

Error in Rate about y [deg/s]

Error in Rate about z [deg/s]

Measurement Error Residual # of CDGPS

Measurements Mean σ Mean σ Mean σ Mean σ Mean σ

1 0.4470 0.2581 0.0300 0.0235 0.0319 0.0263 0.0038 0.0031 0.0131 0.0069

2 0.2669 0.1082 0.0177 0.0121 0.0201 0.0140 0.0035 0.0027 0.0193 0.0075

3 0.2315 0.1068 0.0145 0.0114 0.0150 0.0122 0.0036 0.0030 0.0250 0.0085

The one-measurement simulation performed at times adequately and at times very poorly, with mean attitude error of 0.4470°. This result is expected because the initial estimated attitude quaternion and covariance could not


6

be set by calculating a point solution via the ESOQ method. Instead, the initial attitude is set to a unit quaternion and the covariance to zero. Beyond this initial estimate, only limited information is available to improve the state estimate. The two-measurement simulation performed to within the requirements, with mean attitude error of 0.2669°, and the three-measurement simulation performed the best with mean attitude error of 0.2315°. For CUSat’s mission, the two-measurements simulation reflects the baseline: once a state estimate solution is acquired, one of the three GPS boards will be turned off due to power constraint. Thus leaving 1 CDGPS measurements available from then on.

D. CDGPS CDGPS is a technique for processing raw GPS measurements to calculate highly accurate solutions for relative

measurements. As the name implies, the algorithm differences the carrier-phase measurements, subtracting common sources of error out of the final solution. It uses the phase of the GPS carrier to calculate the vector from one antenna to another. The result is a vector for any pair of antennas that is known in both ECI and body coordinates. A sufficient number of such vector measurements (given the known locations of the antennas) allows the relative attitude and position to be estimated. Ground tests of the flight hardware using either a Spirent GPS simulator or realtime GPS signals show measurement covariance of about 3mm, well within CUSat’s 1 cm relative-position knowledge requirement. The performance is expected to be even better in space, where atmospheric distortion, noise, and possible multipath will have less influence.

The GPS antennas on Top or Bottom are collocated on a single face forming roughly an equilateral triangle with 22cm legs. When the spacecraft separate from each other, angular momentum ensures that these antennas face the same inertial direction. So, each spacecraft’s antennas see the same GPS satellites as one another and the same as the other spacecraft sees. The result is that all six antennas can be used to calculate relative-position vectors for attitude and position estimation.

The CDGPS algorithm executes continuously in its own thread. It reads measurements from the GPS receivers that are stored in global memory and processes them to return vectors determining positions of the GPS receivers from which the measurements were taken, generally in under 10 seconds. The algorithm then stores the resulting vectors back in global memory, providing access for KFATT and MOMS to read the measurements. A single-body mode is used for attitude determination of a single spacecraft (i.e. CUSat before separation), by calculating vectors between GPS antennae on a single spacecraft. A multi-body mode is used to determine the relative position between Top and Bottom by calculating vectors between GPS receivers on the two spacecraft.

E. Attitude Controller The attitude controller can utilize the three-axis IMI reaction wheels on either spacecraft. As a result of

separation from the launch vehicle, the spacecraft spins with some nutation about its minor axis, which over time cones more and more as nutation grows. The attitude controller sends commands through MOMS to the reaction wheels to damp the nutation for this minor-axis spin. The wheels do not directly change the spin rate. Although they function only outside eclipse, the wheels damp nutation eventually, leaving the spacecraft in a simple spin about its minor principal axis in a few orbits.

The gainset used after launch-vehicle separation differs from the gainset used after the spacecraft separate from one another. The former is the more stressing case because the stack is larger than either spacecraft individually, and yet only Top’s wheels are responsible for nutation control of the stack. After separation, the wheels in each spacecraft have considerably more control authority because the transverse inertia of a single spacecraft is so much lower; also, since the maximum-axis spin of the single spacecraft is stable, energy dissipation only helps the nutation control. So, the wheels do not have to work as hard.

F. Position Controller The two spacecraft separate from each other in a way that imparts ΔV as nearly normal to the velocity vector as

possible. This scheme minimizes the relative drift of the two following separation. In principle, not biasing the ΔV to include some along-track component increases the risk of collision half an orbit later. However, Monte Carlo analyses show that the orbit perturbations, alignment errors, and separation-system uncertainty make the likelihood of collision vanishingly small. In fact, the relative drift can be substantial. The position controller is responsible for maintaining the relative orbit mechanics of the two satellites, and it is central to ensuring that Top and Bottom do not drift too far apart for images to be taken. CUSat’s 16 PPTs (8 per spacecraft) are used to accomplish this task.

The position controller collects the CDGPS and GPS pseudorange measurements from MOMS. Then the position controller uses a closed-loop feedback control to calculate the difference in the current and desired orbital momentum vectors, the difference in the current and desired relative semimajor axes, and the direction of each


7

spacecraft’s body angular momentum vector. The thruster-selection algorithm uses these values to calculate the optimal thrusters to fire in order to achieve the desired momentum and velocity. Simultaneously, the attitude-control algorithym damps nutation (at a considerably higher bandwidth, separating the two controllers well). Position control settles in roughly 1-2 weeks of real time. Designed into the architecture of the position controller algorithm is a function to prevent over-firing the thrusters when the spacecraft reaches the correct orientation.9

The relative position is controlled only indirectly. The ground commands a scalar orbital-momentum bias (zero, positive, or negative). Acting like the cruise control that regulates the velocity of car, this bias drives the two spacecraft either to zero, positive, or negative relative orbital velocity. Operators must decide at which point a new momentum-bias command will be uploaded to fine tune the relative position, which is never part of the feedback loop. At the same time, the thrusters continuously operate to keep the two spacecraft’s spin angular momentum vectors aligned so that CDGPS continues to function, and it does so at a bandwidth higher than that of the relative-orbit control but still much lower than that of nutation control. Each PPT provides an impulse of only 60 µNs. So, with these simultaneous objectives, the thruster actuation is saturated for most of the time. The design of the feedback control anticipates this state of affairs: it is based on feedback of rate-related phenomena (such as momentum and energy), which leads to an unconditionally stable system even when the actuators are saturated. Simulations confirm that nonlinearities do not compromise the stability.

G. Fault Protection CUSat’s fault protection provides low-level fault responses. Fault detection continuously checks the hardware

status by comparing the measured values with the safety values determined prior to launch. These fault tests are based on values such as voltage, current, and temperature measurement of hardware components. They also include built-in tests associated with hardware such as the flight computer and the reaction wheels. The fault protection system also checks the health of software by verifying key values in global memory. Single-event upsets (SEUs) are mitigated in the low-level flight code of all boards and in the flight processor, all of which implement redundancy and error checking. The fault responses include overwriting suspect values and power-cycling certain hardware.

The CUSat fault protection architecture comprises three types of tests and resopnses that must work together to ensure the continued maintenance of the health of the spacecraft. The first type of fault management is autonomous, on-orbit fault management. It consists of the functions that are written into the flight code that initiate simple responses to correct problems or prevent behaviors that can damage the spacecraft. The second type of fault management includes the functions written into the flight code that detect anomalies, but raise flags for use by ground operateors and are not allowed to respond with corrective measures. Such faults cause the spacecraft to go into a survival mode, thereby using minimal power. Ground operators must analyze the situation and decide on the appropriate course of action. The third type of fault management consists of the faults that are too subtle to be detected on board but that can be found by careful analysis on the ground, which must respond. Faults in this category are anomalies that are only detectable by recognizing complex combinations of symptoms and telemetry data that the software could never be designed to anticipate.10

III. Subsystems

A. Propulsion CUSat has 16 PPTs total, 8 each on Top and Bottom. The PPTs operate by rapidly discharging the energy stored

in an electrical capacitor, which is charged by the Power Processing Unit (PPU). Discharge occurs across the face of a solid Teflon fuel bar, causing a small amount of Teflon to be converted into a partially ionized gas. Thrust results from both electromagnetism and pressure. The strong electromagnetic field accelerates the ionized particles to 40,000 m/s. The pressure effect thermodynamically accelerates the neutral portion of the gas to about 300 m/s. While the pressure force affects about 80% of the total ablated Teflon, the velocity of the gas is much less than that of the ions. Furthermore, the momentum that pressure imparts to the spacecraft is an order of magnitude lower.


8

a) b) Figure 5. a) CUSat PPTs b) CUSat PPT Locations and Orientations

PPTs are positioned such that CUSat can maneuver in 6 degrees of freedom (DOF) and tolerate a single PPT

failure. Since all PPTs on a spacecraft are controlled by a single PPU, only one PPT per satellite can fire in each firing sequence. A single failed PPU does not end the mission because the other spacecraft has sufficient capability to perform all the required thruster control for the pair. Figure 5b) shows how the PPTs are oriented in each spacecraft. The X axis is oriented as shown in Fig. 5b), the Z axis is normal to the top surface of the satellite, and the Y axis can be determined from X and Z axes.

The electronics that control PPT firing consist of four electronic boards: a Control Board, a Power Board, and two Discharge Initiation (DI) Boards. These boards make up the core of the PPU. The function of the PPU is to charge the appropriate capacitor to fire the PPT igniter, to charge the PPT capacitor, and to control the timing sequence of the PPT firing. After the PPU charges the PPT capacitor and selects the appropriate PPT nozzle to fire, it fires the igniter and discharges the PPT capacitor corresponding to the selected PPT unit. The PPT capacitor produces a high voltage arc and ablates the Teflon fuel bar into plasma. Charged ions are forced out of the PPT nozzle to produce thrust.

The Control Board provides all of the control signals used in the PPU. The main component on the Control Board is the microcontroller. The microcontroller is programmed so that the Control Board provides the necessary signals to the other PPU boards. These signals select the PPT capacitor to charge and the igniter to fire. The Power Board is responsible for providing a 2.8 kV voltage charge the PPT capacitor. The Power Board also provides a 1 kV voltage to charge up the appropriate DI capacitor and to fire the igniter. When the Power Board receives a signal from the Control Board, it supplies these voltages to the PPT capacitor and the DI Boards. The DI Boards hold the DI capacitors that are used to fire the igniters. Each DI Board controls four different capacitors that correspond to the PPT igniters. Upon receiving a signal from the Control Board, the DI Board selects the appropriate capacitor to charge using the voltage received from the Power Board. Then the igniter corresponding to the capacitor fires, initiating a spark and a discharge of the PPT capacitor.11

B. Structure CUSat’s structure is designed to satisfy the requirements specified in the Nanosat-4 User’s Guide12. Those

requirements are as follows: • Machined (milled), all-metallic primary structure shall be used. • Fracture-critical components shall not be used. • The capabilities of non-fracture-critical components shall be readily proven. Examples include

structures designed with redundant load paths, and structures built from machined (milled) metals with well-understood properties with low stresses.

• Welded joints or cast metallic components shall not be used. The basic shape of the CUSat’s structure is a hexagonal prism. This shape maximizes the use of the static

envelope – a right cylinder with 47.5cm in diameter and height – while allowing for easy integration of internal components and large enough solar panels. The structure is comprised of the six rectangular isogrid walls, two hexagonal isogrid walls, a backplane, and a stiffener machined from Aluminum 6061-T651. Additional structural parts include honeycomb panels along with the associated connectors, fasteners, and helicoils. Figure 6 shows an exploded view of Top and Bottom.


9

Figure 6. Top and Bottom Structure Exploded View

Planetary Systems Corporation Motorized Lightbands, one of which is shown in Fig. 7, perform launch vehicle

separation and Top and Bottom separation.

Figure 7. Lightband

The top half of the Lightband is attached to the bottom of both Top and Bottom. The bottom half of the Lightband is attached to the top of Bottom, as well as to the launch vehicle. As shown in Fig. 8, an aluminum mockup of the Lightband is attached to the top of the Top to ensure that the mass and surface area of Top and Bottom are as nearly identical as possible to help ensure the two spacecraft orbit together with minimal environmental perturbations.

Figure 8. Top (left) and Bottom (right)

Thermal analysis identified the need for heaters, which are are incorporated in the battery box. Conduction

pathways are placed in most electrical boxes. Their purpose is to ensure that the active components are maintained within operational temperature limits throughout the mission.13


10

C. Power SpaceQuest designed, built, and tested CUSat’s solar panels. The solar panels use Dual Junction GaAs cells

with an efficiency of 22%. Each cell has an open-circuit voltage of 2.50 V and a peak power voltage of 2.10 V. Each panel was subjected to vacuum and thermal cycling testing by SpaceQuest prior to procurement by CUSat. The solar cells are grouped into strings of seven cells. The panels on top and bottom walls consist of only a single string. The same is true of the panels on the PPT nozzle sides. The larger panels on the other side walls have two strings each. Each panel includes a protection diode for reverse-bias protection in order to stop any negative current from potentially damaging the cells or draining the batteries when the spacecraft not in illumination.

Figure 9. CUSat Battery Box

Table 2. Electrical Specifications for Sanyo NiCd Battery Nominal Capacity 4000 mAh Nominal Voltage 1.2 V

400 mA (Standard) Charge Current 6,000 mA (Fast) 14 – 16 hours (Standard) Typical Charging Time 1 hour (Fast) 0°C – 45°C (Standard) Ambient Temperature 5°C – 40°C (Fast)

As the winner of the UNP-4 flight competition, CUSat is required to use the batteries provided by AFRL – 10

Sanyo NiCd batteries per spacecraft. Figure 9 shows one of the battery boxes. Electrical specifications for each battery are summarized in Table 2.

D. Command and Data Handling CUSat uses Arcom Viper for its flight computer. The development kit is a flight computer electrical board

placed in a complete enclosure with uninterruptible power supply and a touch screen. Figure 10 shows data from a Viper in its development kit, running a test on GPS.


11

Figure 10. Viper in development kit running GPS test

CUSat uses an RS-485 protocol. A bus structure is required in a data link network because the flight computer

and other subsystems must communicate flawlessly. RS-485 was chosen because it has differential lines and is designed for data buses. CUSat uses full-duplex communication, such that there are two twisted-wire pairs linking all subsystems. One twisted-wire pair is used for data transmission from the flight hardware to the subsystems, and the other pair is used for data transmission from the subsystems to the flight computer.

The CUSat Communication Protocol (CUCP) allows all subsystem hardware components to communicate with one another and with the flight code using a defined interface. CUCP also provides error detection and correction mechanisms. CUCP checks to see if the data received by the subsystem is identical to the data sent by the CUCP. If there are discrepancies, CUCP discards the received data by the subsystem, thereby preventing the subsystem from processing incorrect data.

The CUSat flight computer uses Windows CE as its operating system. All of the CUSat lab computers run Windows XP, and all flight code development is done in Microsoft Embedded Visual C++ (eVC++). Downloading code to the flight computer is done through Microsoft ActiveSync.14

E. Telemetry and Control CUSat’s Telemetry and Control (T&C) subsystem serves as the interface between the Space Segment and the

Ground Segment. T&C relays data to and from the ground. CUSat is designed to be nearly autonomous; however, the Federal Communications Commission (FCC) dictates that the spacecraft be capable of being remotely commanded in the event that there is an unforeseen error or interference. In the event of an error or subsystem failure, T&C can receive commands or new flight code from the ground to best correct the situation.

T&C has three functions: downlink, uplink, and crosslink. Downlink refers to all communications originating from one of the spacecraft meant for reception by the ground station. Uplink refers to all communications originating from a ground station, directed toward one of the spacecraft. After Top and Bottom separate, the two spacecraft perform relative navigation by sharing the CDGPS data over the crosslink.

CUSat has four Kenwood TH-D7A dual-band amateur packet radios, two each on both Top and Bottom. They can operate on the 2m and 70cm frequency bands, qualifying them for the 70cm band communication needed for this mission. All four antennas are tuned to the 70cm band. So, only one frequency can be used without interference. This frequency is 437.405 MHz and has been coordinated with the International Amateur Radio Union (IARU) to avoid conflicts with other satellites. The T&C control board communicates with the ham radios in order to transmit and receive data packets.15

CUSat features an optional communication link between T&C and Power subsystems that circumvents the flight computer. The T&C and Power (TCAP) data link enables the ground station to remotely reboot the Flight Computer. This is achieved by sending a reboot command from the ground station to the T&C control board on CUSat. T&C and Power subsystems work in conjunction with each other through a dual-rail communication link, carrying out the timed communication sequence shown in Fig. 11.16


12

Figure 11. TCAP Nominal Sequence

F. GPS CUSat has three GPS receivers each on Top and Bottom. Each GPS receiver has a dedicated antenna. CUSat

uses the Cougar GPS receiver, shown in Fig. 12. This receiver is designed and built by Dr. Paul Kintner’s Space Plasma group at Cornell University. It is based on the Plessey chipset and has been specifically ruggedized for space applications. This receiver has been demonstrated in several sounding-rocket experiments and is robust both in terms of its ability to withstand the launch and space environment and in terms of software issues associated with the very high Doppler shift of receivers in satellite missions.17

Figure 12. Cougar GPS Receiver

G. Camera CUSat uses four COTS Adimec 2000m/s cameras, two each on Top and Bottom. This camera is chosen because

of its ruggedization and the fact that it fits in the bus cavity. The lens mount is an industry standard, allowing for customized viewing angle and lens size. The CameraLink data interface is also an industry standard, allowing for the use of a COTS processing board to communicate with C&DH and the cameras themselves. The Adimec 2000m/s camera was flight qualified by NASA for use on the STS-121 mission. Specifications for the Adimec 2000m/s camera are summarized in Table 3.


13

Table 3. Adimec 2000m/s Camera Specifications Camera Adimec 2000m/s Vibrational Ruggedization 10g half sine Size (l*w*h) cm 8*5*5 Lens Mount C-mount Cost per unit (min qty) $5500 (1) Resolution (h*v) 1920*1080 Interface CameraLink Power Consumption <6W

IV. Mission Operations

A. Mission Objectives CUSat mission has two objectives. Mission Objective 1 is to demonstrate that on orbit CDGPS can support

inspection operations. This objective is motivated by the fact that CDGPS promises centimeter-accurate relative position determination. This technology enables close-proximity navigation for specific uses in on orbit inspection and construction, as well as increasing TRL of CDGPS real-time calculations in space. Mission Objective 2 is to demonstrate an end-to-end autonomous on orbit visual inspection system. In fact, CUSat is an end-to-end system that autonomously inspects objects on orbit and transmits, processes, and telemeters this inspection data. Such a system is a pathfinder for providing in-space surface failure detection and diagnosis, monitoring target system health and operations, and increasing the TRL of GPS-based inspection and navigation systems through demonstration in space.

After the functional checkout at the beginning of the mission, CDGPS vectors will be used on Top for determining the attitude of the spacecraft. Mission Success Criteria 1 (MSC1) is met when CDGPS vectors are correctly computed on orbit for attitude determination of a single body (in this case, CUSat in stacked configuration). MSC2 is met by verifying the accuracy of the CDGPS relative navigation solution to less than 10cm using known values for the distance between GPS antennas. When both MSC1 and MSC2 are met, Mission Objective 1 is completed, and the mission achieves a minimal level of success.

CUSat then transitions to Spacecraft Separation Phase. CUSat achieves the separation state first by stabilizing all roll rates and pointing orbit-normal. In order to separate, CUSat must meet all of the following criteria silmultaneously:

• CUSat is in solar illumination in order to allow the batteries to start charging immediately following the separation maneuver.

• CUSat will have communication opportunities with the Ground Segment for the next 5 orbital passes. • CUSat has sufficient battery capacity to perform separation and inspection maneuvers. • Navigation solutions are acquired on Top, which is then delivered to Bottom. • CUSat is functionally operational. • CUSat has received the separation command from the Ground Segment.

When all of these criteria are simultaneously met, CUSat separates and enters the Inspection Phase, which is the last phase before the End of Life Phase. Following spacecraft separation, Top and Bottom each perform a functional checkout. Crosslink communication is initiated, and CDGPS data is collected between Top and Bottom. This CDGPS data is transmitted back to the ground. MSC3 is met when CDGPS relative vectors are computed on orbit between multiple spacecraft (here, Top and Bottom). MSC4 is met by verifying the accuracy of the CDGPS relative navigation solution to less than 5m using GPS solutions. At this stage, verification does not entail constructing a full 3D surface model or capturing an image. Thus, when both MSC3 and MSC4 are met, Mission Objective 2 is completed, and the mission achieves intermediate level of success.

Afterwards, Top or Bottom captures images of Bottom or Top, respectively, with roughly 1cm2/pixel surface resolution. Image files are downlinked to the ground segment to create a 3D surface model of the spacecraft. MSC5 is met by verifying the accuracy of the CDGPS relative navigation solution to less than 10cm by capturing and processing an image of either Top or Bottom. MSC6 is met when an end user can be presented with a full 3D surface model with 1cm2/pixel surface resolution images taken on orbit.

When both Top and Bottom are about to undergo loss of signal, and if the spacecraft are in view, the ground commands both to downlink all of the inspection data and the logged relative navigation data. This data is used for further analysis of mission performance and will be provided to UNP and other related organizations upon request. Once all data has been downlinked, both Top and Bottom are commanded to enter the End of Life Phase. In the End


14

of Life Phase, both Top and Bottom enter a power positive mode where the spacecraft will ping continuously until loss of signal.

B. Ground Segment The CUSat Ground Segment (GS) is responsible for mission-control operations, which includes the design and

maintenance of the ground stations and the software used to communicate with the spacecraft. GS works closely with Mission Operations subsystem in receiving telemetry and transmitting commands to the spacecraft. CUSat uses several ground stations. One is located in Mount Pleasant, Ithaca, NY, and another at Kwajalein Atoll in the Marshall Islands. As of this writing, CUSat is in the process of coordinating additional ground stations in Redondo Beach, CA, and Boulder, CO.

The overall goal of each ground station is to act as an intermediary by uplinking commands from the MCC to the satellite, and downlinking telemetry, CDGPS measurements, and image data from the spacecraft to the MCC. As such, ground stations need to be modular and flexible to meet changing needs. Each ground station consists of a ground-station computer, an internet connection, a Kenwood TS-2000 transceiver, a Kantronics KAM-XL TNC, a 70cm amateur radio band antenna, a Yaesu G-5500 antenna rotator, a Yaesu GS-232B rotator computer controller, and a mast-mounted pre-amplifier. Figure 13 shows an overview of the Ground Segment architecture including some Space Segment components, and Fig. 14 illustrates how each ground station hardware interacts with the others.

Figure 13. CUSat Ground Segment Architecture


15

Figure 14. CUSat Ground Station Architecture

The InControl software by L-3 Communications serves as the ground-operator interface. InControl consists of

both server and client components. The server side is loaded onto a Windows Server 2003 computer residing on the CUSat network at Cornell, while the client software can be loaded on any computer that can connect to the CUSat network, including computers already on the network. Client computers can view data that is on the server, and multiple computers can view the same data simultaneously. In the CUSat mission-operations environment, most client machines are known as Analyst Stations and are meant for various operators and subsystem representatives to analyze satellite telemetry. Only one client machine can hold a control token, and only the holder of the token is allowed to send commands to the spacecraft in addition to viewing the data. The client computer with control token is generally the one for the Mission Director.18

C. Mission Operations CUSat’s Mission Operations team is responsible for: commanding and monitoring the spacecraft during the

mission, determining how the mission objectives will be achieved, writing procedures for InControl, creating displays for monitoring telemetry, and writing documents on how to operate the satellite during the mission. InControl procedures are series of commands sent in sequence to accomplish a specific task during the mission. Telemetry displays consist of tables or graphs that show the currents, voltages, temperatures, and states of different components of the satellite. Recommended Operating Procedures (ROPs) are documents that explain the background, scope, and steps of a specific procedure in operating the spacecraft. ROPs are used to guide the operators through all possible situations for the specific procedure, including possible errors and alternate paths of operation. The Console Manual is an extensive guide for the operator to follow during the mission. This document includes a list of operating procedures that will be executed in a specific order.

Mission rehearsals are performed to best prepare all personnel who will fly the CUSat mission. They also validate the procedures and debug them. Mission rehearsals are designed to reflect an actual mission environment as much as possible. They are run with the flight code on a flight-space Viper computer in the loop with a MATLAB simulation of the spacecraft dynamics. The simulated data is passed through InControl as if it came from the ground station.

The personnel that are required to be present include the Mission Director, operators, and subsystem representatives. Multiple CUSat team members will be trained for each role, such that shifts can be scheduled during the mission. During the mission, operators will be using InControl to command the spacecraft. The simulator simulates the behavior of the spacecraft as well as ground passes. The timing of these ground passes is calculated by Satellite ToolKit (STK).

The Mission Director ensures that the spacecraft is being commanded properly according to the Console Manual. The Mission Director is also responsible for conferring with the subsystem representatives to ensure that the telemetries are properly monitored. The Mission Director makes all final decisions on the mission, if commands


16

differing from the Console Manual need to be sent to the spacecraft. The majority of actions in the MCC have to be signed off on by the Mission Director. For this reason, the Mission Director must be extremely familiar with both the spacecraft and the mission.

InControl provides the user interface to command the spacecraft and monitor the telemetry during the mission. Operators are members of the Mission Operations team and are required to have significant experience performing this role through mission rehearsals. Operators are also required to be very familiar with the Console Manual, the Sequence of Events, and all of the ROPs.

Subsystem Representatives specialize in a specific bus technical area and provide support as needed. Current areas of specialty include ADCNS, T&C, Power, Survivability, and Payload. Over the course of the mission, different subsystem representatives are consulted, depending on subsystems that will be used during the execution of a given procedure. Each subsystem views telemetry on one of the computers running InControl during the mission. Subsystem representatives also go through a telemetry checklist during the execution of relevant procedures. Telemetry values are recorded on this checklist, which can then be viewed at a later time.19

V. Conclusion CUSat is the first spacecraft to demonstrate feedback conrol with CDGPS. As a university project with a

shoestring budget, CUSat necessarily uses COTS components instead of space-qualified ones, but its architecture makes up for the added risk through fault tolerance. CUSat is manifested for launch in March 2012. In preparation for the launch, the CUSat project team is focusing their efforts on mission rehearsals and ground stations. Going through many mission rehearsals will allow the team to smoothly carry out the actual mission. CUSat team is coordinating with DANDE team – winner of UNP-5 – from University of Colorado, Boulder for the possibility of using each others’ ground stations during the mission for increased coverage. The data will be made available to the public.

Appendix

A. 1, 2, and 3 CDGPS Measurements Simulations for Filter Tuning 1 CDGPS Measurement

-------------- Simulation Results -------------- Number of Simulations: 10 Mean Time to Converge: 32.2 ATTITUDE Results (in deg) Mean KFATT error: 0.447048 STD KFATT error: 0.258121 Mean ESOQ error: 0.897378 STD ESOQ: 0.390124 KFATT Residual: Mean: 0.013077 STD: 0.006866 KFATT RATE Results (in deg/sec) X: Mean KFATT Rate Error: 0.029966 STD KFATT Rate: 0.023529 Y: Mean KFATT Rate Error: 0.031886 STD KFATT Rate: 0.026331 Z: Mean KFATT Rate Error: 0.003776 STD KFATT Rate: 0.003126


17

Figure 15. Normal operation with inertial uncertainty and 1 CDGPS measurement

2 CDGPS Measurements



18

Figure 16. Normal operation with inertial uncertainty and 2 CDGPS measurements

3 CDGPS Measurements



19

Figure 17. Normal operation with inertial uncertainty and 3 CDGPS measurements

Acknowledgments The authors acknowledge the important contributions of the CUSat team members, Cornell Univeristy

Professors Mark Psiaki, Mark Campbell, and Paul Kintner, and the sponsorship of the University Nanosatellite Program, Northrop Grumman Corporation, and the College of Engineering at Cornell University.

References 1Psiaki, M., and Mohiuddin, S., "Modeling, Analysis, and Simulation of GPS Carrier Phase for Spacecraft Relative

Navigation," Journal of Guidance, Control, and Dynamics, Vol. 30, No. 6, 2007, pp. 1628-1639. 2Leung, S., and Montenbruck, O., “Real-time navigation of formation-flying spacecraft using Global Positioning System

measurements,” Journal of Guidance, Control, and Dynamics, Vol 28, No. 2, 2005, pp. 226-235. 3Gershman, D., Young, K., Kelsey, A., Eldad, O., Rostoker, J., Mohiuddin, S., et al., “A GPS-Based Attitude Determination

System for Small Satellites,” 20th Annual AIAA/USU Conference on Small Satellites, SSC06-VII-1, Logan, Utah, 2006. 4Holt, G., Campbell, T., and Lightsey, E., “GPS, Distributed Communications, and Thruster Experiments on the University

of Texas FASTRAC Mission,” AMSAT 22nd Space Symposium and Annual Meeting, Arlington, VA, USA, Oct. 8-10, 2004. 5Kwas, A., and Peck, M., “Ground System Architecture for an Autonomous, Cooperative Inspection Mission,” Ground

System Architectures Workshop 2008, April 1-3, Redondo Beach, California. 6Cassady, R., Hoskins, W., Campbell, M. and Rayburn, C., “A Micro Pulsed Plasma Thruster (PPT) for the “Dawgstar”

Spacecraft,” IEEE Aerospace Conference Proceedings, Big Sky Montana, 18-25 Mar 2000, Vol. 4, pp. 7-14. 7Borowski, H., Reese, K., and Motola, M., “Responsive Access to Space: Space Test Program Mission S26,” Proceedings of

the 2010 IEEE Aerospace Conference, Big Sky, MT, USA, March 6-13, 2010. 8Markley, F. L., and Mortari, D., “How to Estimate Attitude from Vector Observations,” Presented as Paper No. 99-427,

AAS/AIAA Astrodynamics Conference, Girdwood, Alaska, August 16-19, 1999 Proceedings: Advances in the Astronautical Sciences, Vol. 103, pp. 1979-1996, 1999.

9Conrad, P., and Peck, M., “Guidance, Navigation, and Control Architecture for CUSat Nanosatellite Formation,” AIAA Region 1 Annual Conference, Johns Hopkins University Applied Physics Laboratory, Laurel, MD, November 2, 2007.

10Young, K., Fikentscher, J., Kelsey, A., Rostoker, J., Eldad, O., Gershman, D., Doyle, B., Graf, K., and Peck, M., “A GPS-based Attitude Determination System for Small Satellites,” Small Satellite Conference, Logan, Utah, 2006.

11Murakami, N., “Recommended Operating Procedures for the Open Loop Pulsed Plasma Thrusters (PPTs) and Development of Igniter for the PPTs,” Master of Engineering Thesis, Mechanical and Aerospace Engineering, Cornell University, Ithaca, NY, 2008.

12Hunyadi, G., “Nanosat-4 User’s Guide,” UN4-0001, University Nanosat Program Office, Kirtland AFB, NM, 2006. 13Miller, J., “Structural Design Document,” CUSAT-D-STR-001D, Mechanical and Aerospace Engineering, Cornell

University, Ithaca, NY, 2008. 14Brumer, E., “C&DH Analysis,” CUSAT-A-CDH-001B, Mechanical and Aerospace Engineering, Cornell University,

Ithaca, NY, 2008.


20

15Bansal, N., “T&C Design,” CUSAT-D-TC-001C, Mechanical and Aerospace Engineering, Cornell University, Ithaca, NY, 2008.

16Huang, W., “Power Design,” CUSAT-D-PWR-001C, Mechanical and Aerospace Engineering, Cornell University, Ithaca, NY, 2008.

17Peck, M., and Gersh, J., “Systems Architecture for a High-Agility Nanosatellite,” 2009 AAS/AIAA Guidance, Navigation, and Control Conference, August 10-13, Chicago, IL.

18Parsons, N., “Ground Station Design,” CUSAT-GS-002, Mechanical and Aerospace Engineering, Cornell University, Ithaca, NY, 2010.

19Lee, J., “CDGPS and MSC Verification,” B.S. Thesis, Mechanical and Aerospace Engineering, Cornell University, Ithaca, NY, 2010.

Date post:	16-Dec-2016
Category:	Documents
Upload:	mason
View:	214 times
Download:	1 times

[American Institute of Aeronautics and Astronautics Infotech@Aerospace 2011 - St. Louis, Missouri...

Documents