VOLUME II: DESIGN APPENDIX - MIT Space...

162
EMFFORCE DESIGN APPENDIX Space Systems Product Development – Spring 2003 Massachusetts Institute of Technology 1 Dept of Aeronautics and Astronautics VOLUME II: DESIGN APPENDIX PROJECT: EMFFORCE Spring 2003 Space Systems Product Development Professor David Miller

Transcript of VOLUME II: DESIGN APPENDIX - MIT Space...

EMFFORCE DESIGN APPENDIX Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 1 Dept of Aeronautics and Astronautics

VOLUME II:

DESIGN APPENDIX

PROJECT:

EMFFORCE

Spring 2003

Space Systems Product Development Professor David Miller

EMFFORCE DESIGN APPENDIX Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 2 Dept of Aeronautics and Astronautics

TABLE OF CONTENTS

A CONTROL ALGORITHM DEVELOPMENT (LS/AB)................................................................................8 A.1 CONTROL REQUIREMENTS (LS) .........................................................................................................8 A.2 TEST CASES (LS)...................................................................................................................................11 A.3 SYSTEM MODEL (LS)...........................................................................................................................13 A.4 REACTION WHEEL MOTOR MODEL (AB) .......................................................................................16 A.5 CONTROLLER DESIGN (LS)...............................................................................................................18

A.5.1 Test Case 1a.........................................................................................................................................18 A.5.2 Test Case 1b.........................................................................................................................................20 A.5.3 Test Cases 2 and 3 ...............................................................................................................................21 A.5.4 Spin-up.................................................................................................................................................22

A.6 INTERFACING (LS) ...............................................................................................................................30 A.7 CODING CONTROLLERS IN C (AB) ...................................................................................................31 A.8 CONTROLLER CONCERNS AND MITIGATIONS (LS).....................................................................32 A.9 OPTIMAL GAINS (LS, AB) ...................................................................................................................33

A.9.1 Test Case 1...........................................................................................................................................33 A.9.2 Test Case 2...........................................................................................................................................34 A.9.3 Test Case 3...........................................................................................................................................36

B SOFTWARE DOCUMENTATION ...............................................................................................................39 B.1 AVIONICS SOFTWARE AND OPERATING SYSTEM OVERVIEW – MAS (P.1-15) ......................39

B.1.1 Initialization.........................................................................................................................................39 B.1.2 Main function and Operating System (OS) ..........................................................................................43 B.1.3 Avionics Software: Modules ................................................................................................................54

B.2 COMMUNICATIONS SOFTWARE (JEU) ............................................................................................62 B.2.1 Packet Structure...................................................................................................................................62 B.2.2 GUI (ESS) ............................................................................................................................................65 B.2.3 Communication Procedures.................................................................................................................66 B.2.4 Network Structure................................................................................................................................67 B.2.5 DR2000 Communication......................................................................................................................69

B.3 METROLOGY CODE OVERVIEW (OM) .............................................................................................72 B.3.1 Version documentation ........................................................................................................................72 B.3.2 Include Files ........................................................................................................................................72 B.3.3 Input and Output Channels..................................................................................................................72 B.3.4 Global Variables..................................................................................................................................73 B.3.5 Function Prototypes.............................................................................................................................73 B.3.6 Metrology Design Overview ................................................................................................................73 B.3.7 Distance Determination Code..............................................................................................................76 B.3.8 Metrology Software: Modules..............................................................................................................77 B.3.9 Calibration Data..................................................................................................................................78

C AVIONICS HARDWARE DESIGN (SS) ......................................................................................................80 C.1 AVIONICS BOARD INTERFACES.......................................................................................................80 C.2 AVIONICS BOARD WIRING AND SCHEMATIC...............................................................................82 C.3 TT8/AVIONICS BOARD PIN ALLOCATIONS....................................................................................83 C.4 AVIONICS BOARD CAPTURE DRAWING.........................................................................................85 C.5 AVIONICS HARDWARE TESTING .....................................................................................................87 C.6 AVIONICS CIRCUIT BOARD PART INFORMATION .......................................................................88 C.7 PART SPECIFICATION FOR SCREW TERMINALS ..........................................................................89

D CARRIAGE DESIGN (ALS) ..........................................................................................................................92 D.1 GAS SUPPLY ..........................................................................................................................................92

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 3 Dept of Aeronautics and Astronautics

D.2 PUCKS AND CARRIAGE ......................................................................................................................93 E REACTION WHEEL DESIGN (LW, WF) ...................................................................................................97

E.1 ROLE OF RWA (LW) .............................................................................................................................97 E.2 REQUIREMENTS ...................................................................................................................................99 E.3 WHEEL DESIGN (WF).........................................................................................................................100

E.3.1 Material Selection..............................................................................................................................100 E.3.2 Basic Geometry..................................................................................................................................100 E.3.3 Governing Model ...............................................................................................................................100 E.3.4 Structural Integrity ............................................................................................................................102 E.3.5 Vendor Information ...........................................................................................................................103

E.4 MOTOR SELECTION (LW) .................................................................................................................104 E.4.1 Determination of Required Torque....................................................................................................104 E.4.2 Motor Comparisons ...........................................................................................................................105 E.4.3 Motor Selection..................................................................................................................................106 E.4.4 Determination of Required Power .....................................................................................................106 E.4.5 Vendor Information ...........................................................................................................................107

F COIL AND CONTAINMENT DESIGN AND MANUFACTURE (MW, JB)..........................................108 F.1 ELECTROMAGNET SUBSYSTEM REQUIREMENT (MW) ............................................................108 F.2 DESIGN HISTORY (MW) ....................................................................................................................110 F.3 DESIGN OVERVIEW (MW) ................................................................................................................111 F.4 ELECTROMAGNET COIL SIZING (MW)..........................................................................................112 F.5 COIL WRAPPING (MW) ......................................................................................................................115 F.6 COIL TESTING (MW) ..........................................................................................................................117 F.7 CONTAINMENT SYSTEM (JB) ..........................................................................................................121

F.7.1 Requirements: ....................................................................................................................................121 F.7.2 Parts...................................................................................................................................................122 F.7.3 Design and Manufacturing ................................................................................................................123

G METROLOGY SYSTEM DESIGN (AA)....................................................................................................127 G.1 SUBSYSTEM OUTLINE ......................................................................................................................127 G.2 REQUIREMENTS .................................................................................................................................128 G.3 CURRENT SYSTEM DESIGN .............................................................................................................129 G.4 HARDWARE COMPONENT DESIGN................................................................................................130

G.4.1 Structural Support .............................................................................................................................130 G.4.2 Receivers............................................................................................................................................131 G.4.3 Transmitters.......................................................................................................................................133 G.4.4 Rate Gyros .........................................................................................................................................134

G.5 TESTING/VERIFICATION ..................................................................................................................135 G.5.1 Hardware Testing ..............................................................................................................................135 G.5.2 Interfaces ...........................................................................................................................................135 G.5.3 Subsystem Mass .................................................................................................................................136

G.6 RECEIVER CIRRUS LAYOUT............................................................................................................137 G.7 TRANSMITTER LAYOUT...................................................................................................................138 G.8 RECEIVER CIRCUIT DESIGN ............................................................................................................139 G.9 TRANSMITTER CIRCUIT DESIGN....................................................................................................140 G.10 REFLECTIVE CONE DESIGN.............................................................................................................141

H STRUCTURES AND PACKAGING (GG, TS)...........................................................................................143 H.1 PHYSICAL PACKAGING REQUIREMENTS (GG) ...........................................................................143

H.1.1 Power (TS) .........................................................................................................................................143 H.2 PACKAGING DESIGN (GG)................................................................................................................144

H.2.1 System Components ...........................................................................................................................144 H.2.2 Attach Points and Assembly...............................................................................................................144 H.2.3 Attach Points Parts List .....................................................................................................................148

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 4 Dept of Aeronautics and Astronautics

I CODE..............................................................................................................................................................149 I.1 CONTROL TEST CODE (LS, AB)............................................................................................................149

I.1.1 Test Case 1 Code ...............................................................................................................................149 I.1.2 Test Case 2 Code ...............................................................................................................................150 I.1.3 Test Case Three Code ........................................................................................................................152 I.1.4 Spin-up Approach 1 Code..................................................................................................................154 I.1.5 Spin-up Approach 2 Code (has bugs) ................................................................................................158

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 5 Dept of Aeronautics and Astronautics

LIST OF FIGURES

Figure A.1-A: Block Diagram of Controller................................................................................... 8 Figure A.1-B: Spin-up Mode Figure A.1-C: Spin-up Trajectory ............................................. 9 Figure A.1-D: Steady State Spin Mode .......................................................................................... 9 Figure A.1-E: Alpha as a Function of Separation Distance Perturbation ..................................... 11 Figure A.3-A: Definition of States................................................................................................ 13 Figure A.3-B: Model of system for test case 2 ............................................................................. 14 Figure A.3-C: State space equation for tests 2a and 2b ................................................................ 15 Figure A.3-D: State space equation for tests 2a, 2b, and 2c ......................................................... 15 Figure A.5-A: Vehicle response to manual disturbances.............................................................. 20 Figure A.5-B: Vehicle response to commanded inputs ................................................................ 21 Figure A.5-C: EM and Angular Profiles for Constant EM Spin-up ............................................. 25 Figure A.5-D: Torque Profiles for Constant EM Spin-up ............................................................ 25 Figure A.5-E: EM and Angular Profiles for Ramped EM Spin-up .............................................. 26 Figure A.5-F: Torque Profiles for Constant EM Spin-up ............................................................. 26 Figure A.5-G: EM and Angular Profiles for Double Ramped Approach ..................................... 27 Figure A.5-H: Torque Profiles for the Double Ramped Approach .............................................. 27 Figure A.5-I: Profiles for Spacecraft B......................................................................................... 28 Figure A.9-A: Test case 1a weightings......................................................................................... 33 Figure A.9-B: Test Case 1b Weightings ....................................................................................... 33 Figure A.9-C: Test Case 2a weightings ....................................................................................... 34 Figure A.9-D: Test Case 2b weightings........................................................................................ 34 Figure A.9-E: Test Case 2c weightings ........................................................................................ 35 Figure A.9-F: Test Case 2d weightings ........................................................................................ 35 Figure A.9-G: Test Case 3a weightings........................................................................................ 36 Figure A.9-H: Test Case 3b weightings........................................................................................ 36 Figure A.9-I: Test Case 3c weightings ......................................................................................... 37 Figure A.9-J: Test Case 3d weightings ......................................................................................... 38 Figure B-1: Overall Avionics Software Flowchart....................................................................... 44 Figure B-2: Operating System Timing Cycle ............................................................................... 46 Figure B-3: OS Initialization Sequence ........................................................................................ 47 Figure B-4: OS Main Loop Cycle................................................................................................. 51 Figure B.3-A: Metrology System Timing..................................................................................... 74 Figure B.3-B: Beginning Coding Sequence.................................................................................. 75 Figure B.3-C: Loop for usSeq = 0 ................................................................................................ 75 Figure B.3-D: Loop for usSeq = 1 ................................................................................................ 76 Figure B.3-E: Distance Determination Sequence ......................................................................... 77 Figure B.3-F: Distance Calibration............................................................................................... 79 Figure B.3-G: Angle Calibration .................................................................................................. 80 Figure C.1-A: Avionics Hardware Interfaces ............................................................................... 81 Figure C.2-A: Avionics Board Wiring Schematic........................................................................ 83 Figure C.4-A: Avionics Board OrCAD Capture........................................................................... 86

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 6 Dept of Aeronautics and Astronautics

Figure D.2-A: Base ring with pucks attached............................................................................... 93 Figure D.2-B: Close-up view of puck attached to base ring......................................................... 94 Figure E.1-A: Initial Dipole Configuration .................................................................................. 97 Figure E.1-B: Spin-up Configuration ........................................................................................... 98 Figure E.3-A: Basic Geometry of Initial Flywheel Design ........................................................ 100 Figure E.3-B: Final Wheel Design.............................................................................................. 102 Figure E.4-A: Cobalt 625............................................................................................................ 106 Figure F.1-A: Baseline maneuver. Two-vehicle electromagnet dipole system undergoing spin-

up......................................................................................................................................... 108 Figure F.1-B: Induced forces and torques on two dipoles. ........................................................ 109 Figure F.3-A: Electromagnet Coil Design Overview. ............................................................... 111 Figure F.4-A: Two Magnetic Dipoles........................................................................................ 112 Figure F.4-B: Magnetic Moment vs. Mass for 2.0 and 2.5-meter separation distances. ........... 114 Figure F.5-A: Reinforced High temperature superconductor wire............................................ 115 Figure F.5-B: Kapton insulation tape......................................................................................... 115 Figure F.5-C: Outer and inner electromagnet coil cross-sections.............................................. 116 Figure F.5-D: Side-view of the wrapping assembly. ................................................................. 116 Figure F.5-E: Side-view of wrapping spindle............................................................................ 117 Figure F.6-A: Axial B-field Figure F.6-B: Radial B-field Figure F.6-C: Axial B-field..... 119 Figure F.6-D: Magnetic Field in Axial Direction vs. Radius. ................................................... 119 Figure F.6-E: Magnetic Field in Radial Direction vs. Radius. .................................................. 120 Figure F.6-F: Magnetic Field in Axial Direction vs. Height. .................................................... 120 Figure F.7-A: Coils on the Vehicle............................................................................................. 123 Figure F.7-B: Cross Section of the Inner Coil (cm).................................................................... 124 Figure F.7-C: Cross Section of Outer Coil (cm)......................................................................... 124 Figure F.7-D: Spacers for the Male Part of the Container.......................................................... 125 Figure F.7-E: Area of the Tank................................................................................................... 126 Figure F.7-F: Tank ...................................................................................................................... 126 Figure G.4-A: Design of structural support to hold transmitter and receiver circuits. .............. 131 Figure G.4-B: US receiver output calibration............................................................................ 132 Figure G.4-C: US40KT-01 40 kHz Omnidirectional Ultrasound Transmitter (left). ................ 133 Figure G.6-A: Receiver Mounted on Structure support (Left) and Top View of Receiver Circuit

with Cone and Wires Disconnected (Right) ....................................................................... 137 Figure G.6-B: Metrology System mounted on Vehicle .............................................................. 137 Figure G.7-A: Transmitter board mounted on structural support ............................................... 138 Figure G.7-B: Detail view of Transmitter................................................................................... 138 Figure G.8-A: Receiver Circuit Schematic................................................................................. 139 Figure G.9-A: Transmitter Circuit Schematic ............................................................................ 140 Figure G.9-B: Transmitter Circuit Schematic............................................................................. 141 Figure G.10-A: Reflective cone................................................................................................. 142 Figure G.10-B: Reflective cone measurements. ........................................................................ 142 Figure H.2-A: Attach points. ..................................................................................................... 145 Figure H.2-B: Electronics mount. .............................................................................................. 145 Figure H.2-C: Base plate............................................................................................................ 146 Figure H.2-D: U-shaped brace................................................................................................... 146 Figure H.2-E: RWA Cross brace across electromagnet rings.................................................... 147

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 7 Dept of Aeronautics and Astronautics

Figure H.2-F: RWA modified mount......................................................................................... 147 Figure H.2-G: L-brackets attached to foam ring and cross-brace.............................................. 148

LIST OF TABLES Table A.4-1 Reaction wheel motor data ...................................................................................... 16 Table A.5-1: Optimal Gains for Test Case 2a............................................................................... 21 Table A.9-1: Gains for Test Case 1a, I = 0.9 kg*m2.................................................................... 33 Table A.9-2: Gains for Test Case 1a, I = 1 kg*m2....................................................................... 33 Table A.9-3: Gains for Test Case 1b, I = 0.9 kg*m2.................................................................... 33 Table A.9-4: Gains for Test Case 1b, I = 1 kg*m2....................................................................... 33 Table A.9-5: Constants used to calculate gains for Test Case 2................................................... 34 Table A.9-6: Gains for Test Case 2a............................................................................................. 34 Table A.9-7: Gains for Test Case 2b ............................................................................................ 34 Table A.9-8: Gains for Test Case 2c............................................................................................. 35 Table A.9-9: Gains for Test Case 2d ............................................................................................ 35 Table A.9-10: Constants used to calculate gains for Test Case 2................................................. 36 Table A.9-11: Gains for Test Case 3a........................................................................................... 36 Table A.9-12: Gains for Test Case 3b .......................................................................................... 37 Table A.9-13: Gains for Test Case 3c........................................................................................... 37 Table A.9-14: Gains for Test Case 3d .......................................................................................... 38 Table A.9-15: Constants used to calculate gains for spin-up........................................................ 38 Table B-1: Avionics System and Data Size Constants ................................................................. 40 Table B-2: Sensor and Actuator Calibration Constants................................................................ 40 Table B-3: Included Files.............................................................................................................. 41 Table B-4: I/O Channels ............................................................................................................... 41 Table B-5: Function Prototypes (Avionics Software Modules) ................................................... 41 Table B-6: Global Variables ......................................................................................................... 42 Table B-7: Local Variables, main() Function ............................................................................... 47 Table B-8: Elements in the Master State Array (MSA)................................................................ 59 Table B.2-A: DR2000 Protocol Packet Definition (courtesy of the RFM DR2000 Manual)....... 62 Table B.2-B: Communications Cycle Broken Down Into Time Slots.......................................... 68 Table B.3-A: Include Files............................................................................................................ 72 Table B.3-B: Metrology I/O Channels.......................................................................................... 72 Table B.3-C: Global Variables ..................................................................................................... 73 Table B.3-D: Function Prototypes ................................................................................................ 73 Table C.3-A: Avionics IO Pin Allocations ................................................................................... 83 Table C.3-B: Metrology I/O Pin Allocations................................................................................ 84 Table D.2-A: Air Carriage Parts List............................................................................................ 95 Table D.2-B: Tank, bottomline, and regulator assembly.............................................................. 95 Table D.2-C: Manifold assembly.................................................................................................. 96 Table D.2-D: Puck assembly ........................................................................................................ 96 Table E.3-A: Mass Moment of Inertia Values............................................................................ 101 Table E.4-A: Cobalt 625 Motor Specifications .......................................................................... 106 Table G.5-A: Mass Budget. ....................................................................................................... 136

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 8 Dept of Aeronautics and Astronautics

A Control Algorithm Development (LS/AB)

A.1 Control Requirements (LS) Electromagnets and reaction wheels are used to provide the forces and torques necessary to control position and attitude of the vehicles. The interaction between electromagnets of different vehicles can be controlled to either attract or repel the vehicles. The reaction wheels can rotate either clockwise or counterclockwise, providing control to either accelerate or decelerate the vehicles rotationally. Varying the current through the magnets and changing the speed of the wheels control the actuators. Controlling these accurately allows for maneuvering the vehicles and disturbance rejection.

The responsibility of the control team was to build a robust controller for the project that will command maneuvers and provide disturbance rejection. The controller is located on the avionics computer, and processes metrology inputs in order to calculate the necessary commands to send to the actuators. This is depicted in the block diagram in Figure A.1-A.

Figure A.1-A: Block Diagram of Controller

The control team designed controllers to meet the following requirements, derived from the requirements document.

1. Exhibit control in two modes

a. Spin-up/spin-down b. Steady state

2. Build a robust controller for two types of maneuvering a. Trajectory following b. Disturbance rejection

3. Maximum allowable error in separation distance is 15 centimeters for a separation distance of 2 meters between vehicles

+_

Controller

PlantΣ

Sensors

Actual Trajectory

Preprogrammed Trajectory

Metrology Algorithm

Actuators

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 9 Dept of Aeronautics and Astronautics

4. Maximum allowable error in angular position is 5 degrees for each vehicle’s orientation 5. Rotation rate in steady state must be one revolution per minute

The first requirement specifies the modes in which the test-bed operates. This is derived from the test case in which two vehicles are at rest, spin-up to steady state, and then spin-down to rest. Spin-up consists of controlling two vehicles initially at rest and positioned so that the electromagnet of the first vehicle is perpendicular to that of the second, as shown in Figure A.1-B. When the electromagnets are turned on, the vehicles rotate and shear in the directions of the arrows. By controlling the electromagnets and reaction wheels, thereby applying appropriate forces and torques on the vehicles, the vehicles will follow the trajectory specified in Figure A.2-C, where the arrows point to the “north pole” of the magnets. This path will guide the vehicles to the steady state configuration, in which the electromagnets are aligned along a common axis, as show Figure A.1-D, and spinning at a constant rate, Ω, about their common center. Finally, spin-down follows the same trajectory as spin-up but in reverse. In spin-down, as the magnets rotate in the opposite direction relative to the radial line between the electromagnets to align perpendicularly, the test-bed comes to rest. A controller has been designed for spin-up, but has not yet been tested.

Figure A.1-B: Spin-up Mode Figure A.1-C: Spin-up Trajectory

Figure A.1-D: Steady State Spin Mode

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 10 Dept of Aeronautics and Astronautics

To achieve a robust controller implies two responsibilities. The test-bed must both reject disturbances as well as have the control authority to reposition the vehicles. Rejecting disturbances implies both maintaining desired positions and desired angular rates, whether finite or zero in the presence of external disturbances. The controller was designed to demonstrate these capabilities in both the spin-up/spin-down as well as steady-state modes. Repositioning of the vehicles was to be used during the spin-up and spin-down maneuvers by following a user-supplied trajectory. Requirements three and four set the displacement and angular accuracies required for a successful controller. When the controller determines the desired displacement and angular position for each vehicle, they must reach these states with a set accuracy for the controller to work. These accuracies were derived from the accuracy of our system model. The model was obtained by adding a perturbation to the non-linear system dynamics and linearizing the equations of motion. In this process, higher order terms were neglected. To see when these higher order terms become negligible, further analysis was done by comparing the linearized model with the full non-linear model for different size perturbations. The electromagnetic forces on each vehicle due to the electromagnetic interaction between the vehicles were calculated in the x direction for each model. This calculation was done by creating a force balance, as shown in Figure A.1-D. Holding all terms except separation distance constant, the results are as follows:

⎟⎠⎞

⎜⎝⎛ −−

+=− 2201104, 4

323

(1

BABAlinearnonx δr)rF µµµ

πµµµ

π Equation A.1-1

⎟⎠⎞

⎜⎝⎛ −−⎟

⎠⎞

⎜⎝⎛ −= 2201104, 4

323411

BABAlinearx rr

rF µµµ

πµµµ

πδ

Equation A.1-2

where r is the separation distance, δr is a perturbation added to the separation distance, and the µ terms are the magnetic moments for the different coils. The ratio between the linearized forces and non-linear forces is defined as α, where

rr

rr

linearizedlinearnon

δ

δ

α41

114

⎟⎠⎞

⎜⎝⎛ +

=−

=

Equation A.1-3

Substituting two meters for the separation distance r provides Figure A.1-E for α as a function of perturbation size, δr.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 11 Dept of Aeronautics and Astronautics

Figure A.1-E: Alpha as a Function of Separation Distance Perturbation

At alpha equal to one, there is no difference between the linear model and actual model. It was decided that a 10% difference between the models would still produce a functional controller. This difference is shown in the graph by the horizontal lines at alpha equal to 1.1 and 0.9. Therefore, there is less than a 10% difference between models when the distance error is between -0.22m and 0.17m, as shown by the vertical lines. To be conservative, the maximum separation distance error was set at ± 0.15m, guaranteeing less than a 10% difference between the linearized model used to calculate the control and the full non-linear system. A similar approach of analyzing the linearized model was used to determine the maximum allowable angle error. The forces were examined again holding all terms constant except the angle of the magnet with respect to the other magnet. The Mathematica code (available in I.1) was used to try different size angular perturbations and compare the output forces from both the linear and non-linear models. A perturbation of 5 degrees creates a difference of less than 10% between the two models, and therefore is used as the limit for accuracy. Finally, there was a requirement setting the rotation rate in steady state. It must be at least one revolution per minute. This was to limit the duration of testing due to a limited CO2 supply and battery life, as well as to allow the controller to dominate over frictional forces and slopes in the flat floor. At slower speeds, the frictional forces may become significant, creating errors in the system models that do not account for friction. Therefore, it was important to maintain a speed at which friction is not a factor so the system model remains accurate and the controllers are effective.

A.2 Test Cases (LS) There were several steps to designing the controller. The first was to break down the requirements into smaller test cases. For each test case, the system was modeled, a controller

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 12 Dept of Aeronautics and Astronautics

was designed and then coded onto the processor and integrated into the final system. These controllers were then tested and refined. The test cases were defined as follows:

1. One vehicle (only reaction wheel control) 1a. Disturbance rejection 1b. Trajectory following

2. Two vehicles (reaction wheel and electromagnet control) 2a. One vehicle fixed, disturbance rejection 2b. One vehicle fixed, trajectory following and slewing 2c. Both vehicles free, disturbance rejection 2d. Both vehicles free, trajectory following and slewing 2e. Spin-up to steady state, then spin-down.

The first set of test cases uses only one vehicle, so there is no electromagnet control, since this requires a second vehicle with an electromagnet. In Test Case 1a, disturbance rejection was demonstrated by maintaining both a zero rotation rate and finite rotation rate by commanding the reaction wheel. In Test Case 1b, trajectory following was demonstrated by rotating the vehicle to a commanded angle. The second set of test cases adds another vehicle, as well as the use of the electromagnet actuators. In the first two cases, one vehicle is fixed so it cannot move. The other vehicle will demonstrate disturbance rejection as well as trajectory following by moving to commanded separation distances as well as commanded angular positions. In the next two cases, both vehicles are free. Therefore both vehicles can be disturbed as well as commanded to new positions. Finally, a two vehicle spin-up, steady-state spin, and spin-down maneuver must be performed. Originally, a Test Case 3 was designed in which three vehicles would have been controlled. A third vehicle was never built, so the third test case was never tested. Controllers have been designed for this test case, however, and are therefore included as a reference for future work. Test Case 3 was defined as:

3. Three vehicles (reaction wheel and electromagnet control)

3a. Central vehicle fixed, disturbance rejection 3b. Central vehicle fixed, trajectory following and slewing 3c. All vehicles free, disturbance rejection 3d. All vehicles free, trajectory following and slewing 3e. Spin-up to steady state, then spin-down.

The third test case is similar to Test Case 2, with the addition of one more vehicle. In the first two parts of the test, the middle vehicle is fixed and the other two must demonstrate disturbance rejection and slewing. Then all the vehicles are freed. In the final test case, three vehicles must perform the full spin-up, steady state, spin-down maneuver.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 13 Dept of Aeronautics and Astronautics

A.3 System Model (LS) The design of the controller begins with a model of the system. Because each vehicle has inputs from both an electromagnet and a reaction wheel, and there are different states that need to be controlled, a state space model of the system is used to model the system. Since the system has no inertial reference, a coordinate system will be fixed on a specified body. In the diagram below (Figure A.3-A), the coordinate system is fixed on Vehicle A. Here, the states of interest are the distance to the other vehicle (rAB), the angle to the other vehicle from a reference point (θAB), the angle rotated by each vehicle about its own center of mass (αA, αB) from the radial line between vehicles, the rates of these states, as well as the angular rate of the entire system (Ω).

Figure A.3-A: Definition of States

The states are organized into a vector x:

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

Ωαθrαθr

&

&

&x

Equation A.3-1

where the first six states are vectors representing states for each vehicle. These states are named the Master State Array (MSA) and will be computed by metrology, transmitted by communications, and entered as inputs to the controller. By linearizing the equations of motion, system models were developed for each test case of the form:

BuAxx +=& Equation A.3-2

DuCxy += Equation A.3-3

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 14 Dept of Aeronautics and Astronautics

where x are the states, u are the inputs, and y are the measurements. The A and B matrices were determined for each test case with variable system parameters. Estimates were made and used to design the preliminary controllers, and were refined when new system information was known.

For Test Case 1, the desired states were defined as

⎥⎦

⎤⎢⎣

⎡=

θθ&x

Equation A.3-4

where θ is the angular position of the vehicle relative to its initial position, and θ& is its angular rate. The driving dynamics of the system are the torque produced by the reaction wheel, τ, and the resultant torque on the vehicle, Iθ&& . The vehicle was approximated as a cylinder to determine the inertia, I. The output of the system is the gyro reading, or θ& . Putting these into state space form produces:

τ⎥⎥⎦

⎢⎢⎣

⎡+⎥

⎤⎢⎣

⎡=

Ixx 1

0

0010

&

Equation A.3-5

[ ]xy 10= Equation A.3-6

For Test Case 2 the model is a bit more complex, thus we used Mathematica to compute it. Our model of the system uses Figure A.3-B as a reference for the variables in the Mathematica script.

Figure A.3-B: Model of system for test case 2

For the purpose of this paper we will only analyze test case 2. The analysis for test case 3 is done in the same way. Figure A.3-B shows two vehicles, vehicles A and B, each with two electromagnets, magnets 1 and 2. We will use body coordinates fixed on vehicle B, therefore

vehicle B will not translate. The angular position of vehicle A, Aθ , will be measured from the axis connecting vehicle A and vehicle B. We start with the equations of motion where the forces and torques, T and F, are for each of the interactions between the coils – A1, A2, B1, B2 – in the direction indicated, x or y:

xBAxBAxBAxBAA FFFFxm ,2/2,1/2,2/1,1/1 +++=&& Equation A.3-7

yBAyBAyBAyBAA FFFFym ,2/2,1/2,2/1,1/1 +++=&& Equation A.3-8

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 15 Dept of Aeronautics and Astronautics

ARWBABABABAAZA TTTTTI ,2/21/22/11/1, ++++=θ&& Equation A.3-9

BRWABABABABBZB TTTTTI ,2/21/22/11/1, ++++=θ&& Equation A.3-10

By linearizing these equations and dropping the higher order terms, one can construct the state space model of the system. The model for tests 2a and 2b, in the form uxx BA +=& , is shown in Figure A.3-C:

⎥⎥⎥

⎢⎢⎢

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

+

⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢

⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢

=

ARW

A

A

A

A

A

A

A

A

T

IrIrI

rmrm

rmrm

yx

yx

x

,

2

1

ZA,3

ZA,

B103

ZA,

B20

4A

B104

A

B20

4A

B204

A

B10

12--

0415

415

0415

215-

000000000

000000000000000000100000010000001000

µµ

πµµ

πµµ

πµµ

πµµ

πµµ

πµµ

θ

θ

&

&

&&

Figure A.3-C: State space equation for tests 2a and 2b

And the model for tests 2c, 2d, and 2e is given in Figure A.3-D:

⎥⎥⎥⎥

⎢⎢⎢⎢

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

+

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

BRW

ARW

A

A

B

A

A

A

B

A

A

A

TT

IrIrI

IrIrI

rmrm

rmrm

yx

yx

x

,

,

2

1

ZB,3

ZB,

B103

ZB,

B20

ZA,3

ZA,

B103

ZA,

B20

4A

B104

A

B20

4A

B204

A

B10

10-2-

012--

00415

415

00415

215-

0000000000000000

0000000000000000000000000000000010000000010000000010000000010000

µµ

πµµ

πµµ

πµµ

πµµ

πµµ

πµµ

πµµ

πµµ

θθ

θθ

&

&

&

&&

Figure A.3-D: State space equation for tests 2a, 2b, and 2c

where 22AA yxr += .

The key difference between these models is the fact that for tests 2c, 2d, and 2e vehicle B is not fixed, allowing for the use of its reaction wheel for control. The state space models for test case 3 are similarly found. The state space models above were computed using specific values for the field strengths of the magnets on the fixed vehicle. The model will have to be recomputed to get the correct gains for different test case setups.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 16 Dept of Aeronautics and Astronautics

A.4 Reaction Wheel Motor Model (AB) The reaction wheel assembly, which controls the attitude of the vehicle, is powered by a single motor mounted in the center of the vehicle. The behavior of the motor is essential to overall vehicle dynamics. The motor behavior was modeled to extract constants needed for the controller. The controller used initially for the motor used proportional control. The proportional controller did not provide precise enough control, so a first-order model was derived, beginning with the relationships:

VkkR

bT et

a =++ ωω)( Equation A.4-1

ikT t= Equation A.4-2

where T is motor torque, b is a frictional constant, ω is the rate at which the motor shaft spins,

aR is the armature resistance of the motor, tk and ek are torque constants, and V is the voltage required by the motor. If you assume that the current supplied to the motor remains constant, only the frictional constant needs to be found. The frictional constant, b was found experimentally. The wheel was mounted on the motor and spun up to maximum speed. The motor was then turned off and measurements of ω were taken at regular intervals until the wheel came to a complete stop. The rate of rotation measurements were taken with the tachometer. Test data is shown in Table A.4-1 below. The time shown is the time since the motor was turned off.

Table A.4-1 Reaction wheel motor data

Time (s) Trial 1 - ω (Hz) Trial 2 - ω (Hz) 0 208 185 5 185 161

10 172 156 15 155 135 20 138 125 25 122 111 30 106 96 35 102 87 40 87 75 45 75 64 50 67 54 55 57 43 60 45 34 65 34 26 70 27 19 75 20 12 80 12 6

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 17 Dept of Aeronautics and Astronautics

The frictional constant b was derived from the relationship:

ikbI twheel =+ ΘΘ•••

Equation A.4-3

giving a value of b:

000379.0−=b skgm 2

Equation A.4-4

We also tried to make a better model by taking out our constant current assumption. We abandoned this as soon as the first order model was found to work but I will include the work here anyway. Integration of Equation A.5-3 gives:

a

tLR

RVceti a

a

+=−

)( Equation A.4-5

Taking data on the motor and solving Equation A.5-4 graphically for inductance gives:

51033.1 −×=aL H Equation A.4-6

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 18 Dept of Aeronautics and Astronautics

A.5 Controller Design (LS) The technique of control design used for the test-bed was the linear quadratic regulator, providing an optimal controller. The LQR approach minimizes the cost equation:

( )∫ += dtuRuxRxJ uuT

xxT

Equation A.5-1

where J is the cost, x is the state, u is the control input, Rxx is the cost associated with state, and Ruu is the cost associated with the control. When importance is placed on state accuracy, and the amount of control, or current to the actuators, is less important, Rxx is weighted high. When minimizing the amount of control used is more important than the accuracy of the state, Ruu is weighted high. To find the minimal cost J, the following equation must be solved for P:

PBPBRPAPAR Tuu

Txx

10 −−++= Equation A.5-2

where A and B are the same matrices found in modeling the system. The value of P can be used to find the optimal gains, F, for the system, where:

PBRF Tuu

1−= Equation A.5-3

The optimal control is then,

Fxu −= Equation A.5-4 Substituting into Equation A.4-2, the closed loop A matrix can be determined, where

BFAACL −= Equation A.5-5

This was calculated in Matlab using the LQR command. After determining the A and B matrices, as well as the weightings for Rxx and Ruu, these values are entered as parameters for the LQR function.

[ ] ( )uuxx RRBAlqrESF ,,,,, = Equation A.5-6

A.5.1 Test Case 1a The angular rate of the vehicle was controlled through a simple feedback gain, using a rate gyro for feedback. This gain was determined using LQR techniques. For this disturbance rejection case, the weightings were set to

41

10010 5

=⎥⎦

⎤⎢⎣

⎡=

uuxx RR Equation A.5-7

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 19 Dept of Aeronautics and Astronautics

In the actual code, the matrix entries of zero were replaced with finite numbers due to the fact that singularities were being created in the LQR function. The higher weighting on θ& in Rxx

compared to the Ruu weighting indicates that it is more important to have an accurate θ& than it is to conserve control energy. The weightings along the diagonal of Rxx place more importance on the second state, θ& , than on the first state. This is because in disturbance rejection, the actual position is not controlled. The rate of change of position is driven to zero, and therefore the rate is weighted more heavily. These weightings were used in Matlab with the A and B matrices from Equation A.4-5. For an inertia of 1 kg*m2, the optimal gains are:

[ ]20063.0=F Equation A.5-8 This inertia estimate includes the weight of the LN2. If the test was run without the coils filled, the inertia estimate lowers to 0.9 kg*m2 but the gains remain unaffected at

[ ]20063.0=F Equation A.5-9

The controller was tested on a vehicle by giving manual disturbances. The vehicle successfully returned to a zero position, as shown in Figure A.5-A.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 20 Dept of Aeronautics and Astronautics

Figure A.5-A: Vehicle response to manual disturbances

A.5.2 Test Case 1b A controller was designed for Test Case 1b, a tracking problem. The same system model was used for this problem. However, different costs were assigned, as shown below:

41

10001

4 =⎥⎦

⎤⎢⎣

⎡= − uuxx RR

Equation A.5-10

In this case, the weightings along the diagonal of Rxx place more importance on the first state, θ . In a tracking problem, the specific position is more important than the rate of change of the position. The accuracy of the state is still more important than the amount of control used, as shown in the difference in magnitude between Rxx and Ruu. The new gains for were found to be:

[ ]898.1000.2=F I = 0.9 kg*m2 Equation A.5-11

[ ]001.2000.2=F I = 1 kg*m2 Equation A.5-12 Comparing these gains to those calculated for Test Case 1a shows how the relative gain on θ increases in the slewing case of 1b, reflecting the shift in importance of position.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 21 Dept of Aeronautics and Astronautics

This controller was tested by providing inputs, commanding the vehicle to rotate to different angles. There was a fairly significant time lag, which can be improved by tweaking the gains. The results of this test are shown in Figure A.5-B.

Figure A.5-B: Vehicle response to commanded inputs

A.5.3 Test Cases 2 and 3 Optimal gains were determined for Test Cases 2 and 3 in the same manner using the system models described above. Weightings were chosen in a similar fashion to the ones chosen for test case one, with the rates weighted more for disturbance rejection, and the positions weighted more for trajectory following. In all cases the states were weighted more heavily than the control. Sample gains for Test Case 2a are shown below in Table A.5-1. A vehicle mass of 15 kg was used, with an inertia of 1 kg*m2 for both vehicles.

Table A.5-1: Optimal Gains for Test Case 2a

Ax Ay Aθ Ax& Ay& Aθ&

-0.0063 0.0004 -0.0000 -23.9293 1.9237 -0.0000 1Aµ

0.0004 0.0063 -0.0000 1.9237 33.7807 -0.0003 2Aµ

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 22 Dept of Aeronautics and Astronautics

0.0000 0.0000 0.0089 0.0001 0.0060 2.8316 ARW ,τ

There is a gain associated with each state and input pair. Only the states and inputs of vehicle A are used in Test Case 2a because the other vehicle is fixed. The states of interest are listed across the top row with the subscript A referring to vehicle A, and the inputs are listed in the last column. Here, x and y are the rectangular decomposition of the position r described in Table A.5-1 above. The inputs µA1 and µA2 refer to the current needed to drive the two electromagnet coils per vehicle, and τRW,A is the torque required from the reaction wheel. Because Test Case 2a is a disturbance rejection problem, the gains associated with the rates are higher. The rest of the gains are given in section A.9. For Test Case 3, a vehicle mass of 15 kg was used and an inertia of 1.0547 kg*m2 was used. There are no optimal gains listed for Test Cases 2e and 3e. This is due to the fact that the gains necessary for these maneuvers were already calculated in Test Cases 2c, 2d, 3c, and 3d. To perform Test Case 2e, a trajectory following controller should be implemented using the gains from Test Case 2d during spin-up and spin-down, while a disturbance rejection controller should be implemented using the gains from Test Case 2c during the steady state spin. In the same way, the gains from Test Case 3d should be used in a trajectory following controller during the spin-up and spin-down of Test Case 3e, while the gains from Test Case 3c should be used in a disturbance rejection controller during the steady state spin.

A.5.4 Spin-up Input trajectories are necessary to dictate the spin-up and spin-down processes. While several approaches have been explored for Test Case 2e, no trajectory has been calculated for Test Case 3e. Three initial approaches to performing spin-up case 2e were explored by specifying a magnet current profile and determining the necessary reaction wheel profiles to perform spin-up. The first approach was to turn on the magnets to the current necessary to hold the vehicles in place during steady state spin. A reaction wheel profile was then determined to rotate the vehicles to align for steady state. The current necessary for this maneuver was calculated by solving the following force equation for the magnetic moment µ = µA = µB:

rmr

F BAradEM

24

0, )2(4

3 θµµµ

π&=

−=

Equation A.5-13

where µ0 = 4πe-7, r is the 1 meter distance between vehicles, m is the mass of each vehicle at 20 kg, and θ& is the rotation rate of the array, set to 1 rpm. The value for µ was then plugged into the equation:

niA=µ Equation A.5-14

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 23 Dept of Aeronautics and Astronautics

where n, the number of wraps in the coil, is 100 and A is the area of the coil, using 0.83 meters for the diameter. The steady state current necessary using these values was found to be 44.7 amps. To find the torque profile, the following equations of motion were used:

mrθ)θθθθ(r

µµµπ

mrθFθmr BAABBA

EM,TAN &&&&&& 2cossincossin432 4

0 −+=−= Equation A.5-15

rm)θθθθ(r

µµµπ

rθmFrm ABBABA

EM,RAD2

402 sinsincoscos2

43 θ&&&& +−−=+=

Equation A.5-16

They were discretized to the form:

0

00,0,0,0,5

0

00

2cossincossin

431

rrθ

)θθθθ(r

µµµπn

θ BAABBA &&&& −+=

Equation A.5-17

02

00,0,0,0,40

00 sinsincoscos2

431 r)θθθθ(

rµµµ

πnr ABBA

BA θ&&& +−−= Equation A.5-18

The initial conditions used to find the torque profile were:

• θA,0 = θA = 0, from keeping the coordinate system fixed on vehicle A, • θB,0 = 90o, starting the magnet for vehicle B perpendicular to the magnet of vehicle A, • r0 = r = 1m, keeping the radius between vehicles constant,

• 0θ& = θ0 = 0 • r& = r&& = 0. The final conditions were:

• θB,final = 0o

• sradfinal /

602πθ =&

The following process is then iterated to find the torque profile:

dt001 θθθ &&&& += Equation A.5-19

mrFRAD 12

11, θ&= Equation A.5-20

⎟⎟⎠

⎞⎜⎜⎝

⎛ −= −

1

41,1

1,

)2(cos

krFRAD

Bθ Equation A.5-21

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 24 Dept of Aeronautics and Astronautics

( )dt

BBB

0,1,1,

θθθ

−=&

Equation A.5-22

( )1,1,41

1, cossincossin)2( BAABTAN r

kF θθθθ += Equation A.5-23

mrFTAN 1,=θ&&

Equation A.5-24

where πµµµ

43 0 BAk −=

, a constant for this method.

The torques on the electromagnets are calculated from the following equations:

))cos()sin(2)sin()(cos()2( 3, BABAzAEM r

k θθθθτ += Equation A.5-25

))cos()sin()sin()cos(2()2( 3, BABAzBEM r

k θθθθτ += Equation A.5-26

The torques on the reaction wheels are calculated from the following equations:

xAEMARW Imr ,2

, )( τθτ ++−= && Equation A.5-27

xBEMBBRW IImr ,2

, )( τθθτ +++−= &&&& Equation A.5-28

The profiles are shown in Figure A.5-C and Figure A.5-D:

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 25 Dept of Aeronautics and Astronautics

Figure A.5-C: EM and Angular Profiles for Constant EM Spin-up

Figure A.5-D: Torque Profiles for Constant EM Spin-up

As shown in the graphs, this spin-up approach takes 25 seconds. The spike towards the end of the torque profile for reaction wheel B is due to a numerical error from a differentiation and does not reflect an actual physical occurrence. To test that this is true, the time step was changed and examined. The spike remained the same number of time steps from the end, indicating there was a numerical problem, not a physical problem. To slow down spin-up, a second approach was explored. A ramp input was chosen for the electromagnet. The code written allows variable lengths for the ramp. For this case, a ramp time of 70 seconds was chosen to bring the electromagnet currents from 0 amps to the steady state

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 26 Dept of Aeronautics and Astronautics

value 44.7 amps. This whole approach takes 85 seconds to complete, as shown in Figure A.5-E and Figure A.5-F.

Figure A.5-E: EM and Angular Profiles for Ramped EM Spin-up

Figure A.5-F: Torque Profiles for Constant EM Spin-up

Once again, a numerical error caused the spike in reaction wheel B. The final approach explores a quicker spin-up profile by ramping the current in the electromagnets to twice the amount needed for steady state spin, and then ramping back down to the steady state current. The code for this case also allows variable ramp times. In the following graphs (Figure A.5-G and Figure A.5-H), the electromagnetic current is ramped up to twice the steady state value in one second, held at that value for another 8 seconds, and then ramped down to the steady state value in another second.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 27 Dept of Aeronautics and Astronautics

Figure A.5-G: EM and Angular Profiles for Double Ramped Approach

Figure A.5-H: Torque Profiles for the Double Ramped Approach

All three options present feasible electromagnet and reaction wheel profiles (with the exception of the numerical errors). Depending on the time constraints of spin-up and torque limits, one of these spin-up profiles could be chosen. However, examining the profiles for the angle of spacecraft B shows that the vehicle would quickly rotate towards a 90-degree turn and need to abruptly stop. This would require a lot of effort from the torque wheels to prevent overshoot in the turns. For this reason, another approach to spin-up was explored using a pre-determined angular profile for vehicle B to determine the required electromagnet and reaction wheel profiles. In this approach, a profile for the angle of vehicle B (Figure A.5-I) is modeled as a section of a

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 28 Dept of Aeronautics and Astronautics

cosine wave, so the angle slowly approaches its end value. Differentiating this, an initial and final acceleration are specified, despite the fact that the initial and final angular velocities are zero.

Figure A.5-I: Profiles for Spacecraft B

The initial acceleration will be created when the electromagnets are turned on. The final acceleration can be counteracted with the reaction wheels. It seems more feasible to counteract this acceleration with the reaction wheels than to counteract the increasing rotational velocity of the spacecraft from the first approach due to the fact that the velocity is approaching zero in the second case. Electromagnet and reaction wheel profiles have not been determined due to an error in the code. However, the approach to calculate them is described in the following equations. The same initial conditions will be used for this approach. The angle of spacecraft B is specified by the following equation:

4cos

4)( πππθ +⎟

⎟⎠

⎞⎜⎜⎝

⎛= t

tt

fB

Equation A.5-29

FRad1 is calculated using equations A.5-19 and A.5-20. Then, the magnetic moments can be calculated.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 29 Dept of Aeronautics and Astronautics

))sin()sin()cos()cos(2( 1,1,1

1,1,1,

ABBA

RadBA k

Fθθθθ

µµ+

−= Equation A.5-30

where 4

01 )2(4

3r

π=

. Then use

)cos()sin()cos()(sin( 1,1,1,1,11, BAABBATan kF θθθθµµ += Equation A.5-31

mrFTan 1,

1 =θ&& Equation A.5-32

along with Equations A.5-25 through A.5-28 to determine the reaction wheel profiles. The electromagnet current profiles can be calculated using Equations A.5-14 and A.5-30.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 30 Dept of Aeronautics and Astronautics

A.6 Interfacing (LS) The main interfacing of the control team is with avionics, due to the fact that the controller will be located on the avionics computer. Preliminary discussions regarding the size and amount of the computations done by the controller helped decide what processor the avionics team chose. Interfacing with metrology is necessary to determine the accuracy of the metrology sensing. Also, the interfacing determines which inputs the control team needs from metrology, and which inputs the metrology team is capable of providing. This also includes the communications team, who decides how this information is transmitted. The final decision for this interfacing includes a Primary Vehicle Array (PVA) that consists of the data from the metrology sensors, and a MSA, which consists of the state information to be inputted into the controller. Each vehicle will send its PVA to the other vehicles. The three PVAs can then be compiled by each vehicle into an MSA, which will be sent to the controller.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 31 Dept of Aeronautics and Astronautics

A.7 Coding Controllers in C (AB) The next step in creating a controller was to code it into C. An advantage to using an LQR controller was the fact that all we needed to do was multiply the states by the gains, a simple matrix multiplication, to generate control output values. For Test Case 1 our states are angle and angular rate. For the one vehicle case, however, we could only sense angular rate. Therefore to solve for the angle we integrated our angular rate over time. This was easily handled in the code. For Test Case 1b, we also had to add in a desired state and have this state change over time so that the vehicle would perform a preprogrammed maneuver. Since the controller is a Linear Quadratic Regulator it is constantly trying to keep a state at its nominal value. To make the vehicle move then one must “trick” the vehicle into thinking it is not at its nominal value and wait for the vehicle to correct to the new nominal value. To accomplish this we simply subtracted the desired state from the input we received. For example, say the nominal angle value was zero. If you wanted to move the vehicle 30 degrees you would subtract 30 degrees from the input. This makes the vehicle think it’s at -30 degrees thus the controller works to bring it back to the nominal. The code for Test Case 2 is pretty straightforward. It runs off the same basic framework stated above. It reads the variables in to a state array, multiplies this array by the gains matrix, and writes the results into an output commands array. Trajectory following is handled just like in Test Case 1b, where the vehicle is tricked into thinking that it is not at the nominal state.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 32 Dept of Aeronautics and Astronautics

A.8 Controller Concerns and Mitigations (LS) The control team has several concerns that have arisen during the design process. These include near field effects, the time constant of the electromagnets, and coding of the controllers. The first concern arises because the system models were made using equations that are valid for the far field approximation of the electromagnet effects. The far field assumption is determined by the size of the electromagnets and their separation distances. If the electromagnets move closer into the near field, the model becomes less accurate. The time constant of the electromagnet determines how quickly the current in the electromagnet and therefore the field produced by the electromagnet can be changed. The time constant required by the control team to successfully control the electromagnet is determined by the rotation rate of the system. If the time constant of the electromagnet proves to be slower than what is needed to control effectively, the rotation rate of the system must be slowed. The electromagnetic field must be able to be changed faster than the controller requires a change to perform maneuvers.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 33 Dept of Aeronautics and Astronautics

A.9 Optimal Gains (LS, AB)

A.9.1 Test Case 1

41

10010 5

=⎥⎦

⎤⎢⎣

⎡=

uuxx RR

Figure A.9-A: Test case 1a weightings

Table A.9-1: Gains for Test Case 1a, I = 0.9 kg*m2

θ θ&

0.0063 2.003 RWτ

Table A.9-2: Gains for Test Case 1a, I = 1 kg*m2

θ θ&

0.0063 2.003 RWτ

41

10001

4 =⎥⎦

⎤⎢⎣

⎡= − uuxx RR

Figure A.9-B: Test Case 1b Weightings

Table A.9-3: Gains for Test Case 1b, I = 0.9 kg*m2

θ θ&

2.000 1.898 RWτ

Table A.9-4: Gains for Test Case 1b, I = 1 kg*m2

θ θ&

2.000 2.001 RWτ

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 34 Dept of Aeronautics and Astronautics

A.9.2 Test Case 2

Table A.9-5: Constants used to calculate gains for Test Case 2

µB,1 µB,2 mA IA= IB r

1767.1 A*m2 176.71 A*m2 15 kg 1 kg*m2 2 meters

Figure A.9-C: Test Case 2a weightings

Table A.9-6: Gains for Test Case 2a

Ax Ay Aθ Ax& Ay& Aθ&

-0.0063 0.0004 -0.0000 -23.9293 1.9237 -0.0000 1Aµ

0.0004 0.0063 -0.0000 1.9237 33.7807 -0.0003 2Aµ

0.0000 0.0000 0.0089 0.0001 0.0060 2.8316 ARW ,τ

⎥⎥⎥

⎢⎢⎢

⎡=

⎥⎥⎥⎥

⎢⎢⎢⎢

=125.000025.000025.0

100010001

uuxx RR

00

0

Figure A.9-D: Test Case 2b weightings

Table A.9-7: Gains for Test Case 2b

Ax Ay Aθ Ax& Ay& Aθ&

-1.9956 0.1330 -0.0000 -424.0485 34.1238 -0.0000 1Aµ

0.1330 1.9956 -0.0002 34.1239 599.6666 -0.0002 2Aµ

0.0000 0.0004 2.8284 0.0023 0.1063 2.3784 ARW ,τ

⎥⎥⎥

⎢⎢⎢

⎡=

⎥⎥⎥⎥

⎢⎢⎢⎢

=125.000025.000025.0

100010001

uuxx RR0

00

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 35 Dept of Aeronautics and Astronautics

⎥⎥⎥⎥

⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢

=

125.00000125.0000025.0000025.0

1000010000100001

uuxx RR 0

00

Figure A.9-E: Test Case 2c weightings

Table A.9-8: Gains for Test Case 2c

Ax Ay Aθ Bθ Ax& Ay& Aθ& Bθ&

-0.0063 0.0004 -0.0000 -0.0000 -23.9293 1.9237 -0.0000 -0.0000 1Aµ

0.0004 0.0063 -0.0000 -0.0000 1.9237 33.7807 -0.0003 -0.0001 2Aµ

0.0000 0.0000 0.0089 -0.0000 0.0001 0.0060 2.8316 -0.0000 ARW ,τ

-0.0000 0.0000 -0.0000 0.0089 -0.0003 0.0030 -0.0000 2.8316 BRW ,τ

⎥⎥⎥⎥

⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢

=

125.00000125.0000025.0000025.0

1000010000100001

uuxx RR

00

0

Figure A.9-F: Test Case 2d weightings

Table A.9-9: Gains for Test Case 2d

Ax Ay Aθ Bθ Ax& Ay& Aθ& Bθ&

-1.9956 0.1330 -0.0000 -0.0000 -424.0485 34.1238 -0.0000 -0.0000 1Aµ

0.1330 1.9956 -0.0002 -0.0001 34.1238 599.6666 -0.0002 -0.0001 2Aµ

0.0000 0.0004 2.8284 -0.0000 0.0023 0.1063 2.3784 -0.0000 ARW ,τ

-0.0000 0.0002 -0.0000 2.8284 -0.0045 0.0536 -0.0000 2.3784 BRW ,τ

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 36 Dept of Aeronautics and Astronautics

A.9.3 Test Case 3

Table A.9-10: Constants used to calculate gains for Test Case 2

µB,1 µB,2 mA= mB= mB IA= IB= IC rAB=rBC

1767.1 A*m2 176.71 A*m2 15 kg 1 kg*m2 2 meters

⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

125.0000000125.000000025.000000025.000000025.000000025.0

100000010000001000000100000010000001

uuxx RR 0

00

Figure A.9-G: Test Case 3a weightings

Table A.9-11: Gains for Test Case 3a

Ax Bx Ay By Aθ Bθ Ax& Bx& Ay& By& Aθ& Bθ&

-0.0063 0 0.0004 0 0 0 -23.9293 0 1.9237 0 0 0 1Aµ

0.0004 0 0.0063 0 0 0 1.9237 0 33.7807 0 -

0.0003 0 2Aµ 0 -0.0063 0 0.0004 0 0 0 -23.9293 0 1.9237 0 0 1Bµ 0 0.0004 0 0.0063 0 0 0 1.9237 0 33.7807 0 -0.0003 2Bµ 0 0 0 0 0.0089 0 0.0001 0 0.006 0 2.8318 0 ARW ,τ 0 0 0 0 0 0.0089 0 0.0001 0 0.006 0 2.8318 BRW ,τ

⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

125.0000000125.000000025.000000025.000000025.000000025.0

100000010000001000000100000010000001

uuxx RR

00

0

Figure A.9-H: Test Case 3b weightings

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 37 Dept of Aeronautics and Astronautics

Table A.9-12: Gains for Test Case 3b

Ax Bx Ay By Aθ Bθ Ax& Bx& Ay& By& Aθ& Bθ&

-1.9956 0 0.133 0 0 0

-424.04

9 0 34.1238 0 0 0 1Aµ

0.133 0 1.995

6 0

-0.000

2 0 34.123

8 0 599.666

6 0

-0.000

2 0 2Aµ

0

-1.995

6 0 0.133 0 0 0

-424.04

9 0 34.1238 0 0 1Bµ

0 0.133 0 1.995

6 0

-0.000

2 0 34.123

8 0 599.666

7 0

-0.000

2 2Bµ

0 0 0.000

4 0 2.828

4 0 0.0023 0 0.1063 0 2.442

6 0 ARW ,τ

0 0 0 0.000

4 0 2.828

4 0 0.0023 0 0.1063 0 2.442

6 BRW ,τ

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

125.00000000125.00000000125.0000000025.0000000025.0000000025.0000000025.0

10000000100000001000000010000000010000000100000001

00

uuxx RR

Figure A.9-I: Test Case 3c weightings

Table A.9-13: Gains for Test Case 3c

Ax Bx Ay By Aθ Bθ Cθ Ax& Bx& Ay& By& Aθ& Bθ& Cθ&

-0.0063 0 0.0004 0 0 0 0 -

23.9293 0 1.9237 0 0 0 0 1Aµ 0.0004 0 0.0063 0 0 0 0 1.9237 0 33.7807 0 -0.0003 -0.0001 0 2Aµ

0 -

0.0063 0 0.0004 0 0 0 0 -

23.9293 0 1.9237 0 0 0 1Bµ 0 0.0004 0 0.0063 0 0 0 0 1.9237 0 33.7807 0 -0.0001 -0.0003

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 38 Dept of Aeronautics and Astronautics

0 0 0 0 0.0089 0 0 0.0001 0 0.006 0 2.8318 0 0 0 0 0 0 0 0.0089 0 -0.0003 -0.0003 0.003 0.003 0 2.8318 0 0 0 0 0 0 0 0.0089 0 0.0001 0 0.006 0 0 2.8318

⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥⎥

⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢⎢

=

125.00000000125.00000000125.0000000025.0000000025.0000000025.0000000025.0

1000000010000000100000001000000010000000100000001

uuxx RR

00

0

Figure A.9-J: Test Case 3d weightings

Table A.9-14: Gains for Test Case 3d

Ax Bx Ay By Aθ Bθ Cθ Ax& Bx& Ay& By& Aθ& Bθ& Cθ&

-1.9956 0 0.133 0 0 0 0 -424.049 0 34.1238 0 0 0 0 1Aµ

0.133 0 1.9956 0 -0.0002 0.0001 0 34.1238 0 599.6666 0 -0.0002 -0.0001 0 2Aµ

0 -1.9956 0 0.133 0 0 0 0 -424.049 0 34.1238 0 0 0 1Bµ

0 0.133 0 1.9956 0 0.0001 -0.0002 0 34.1238 0 599.667 0 -0.0001 0.0002 2Bµ

0 0 0.0004 0 2.8284 0 0 0.0023 0 0.1063 0 2.4426 0 0 ARW ,τ

0 0 0.0002 0.0002 0 2.8284 0 -0.0045 -0.0045 0.0536 0.0536 0 2.4426 0 BRW ,τ

0 0 0 0.0004 0 0 2.8284 0 0.0023 0 0.1063 0 0 2.4426 CRW ,τ

Spin-up

Table A.9-15: Constants used to calculate gains for spin-up

R rr &&& = m Ω n dcoil iss, EM AA θθ =0, 0,Bθ finalB ,θ

I

1 meter 0 20 kg 1 rpm 100 wraps

0.83 m 44.7 Amps

0 90o 0o 1 kg*m2

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 39 Dept of Aeronautics and Astronautics

B Software Documentation The software in the EMFF system can be initially grouped by its physical location: avionics software on the avionics Tattletale, metrology software on the metrology Tattletale, and ground station software on the EMFF laptop. The avionics Tattletale (TT8) houses software for avionics, communication, and control; the ground station and metrology TT8 computers each hold the majority of their own subsystems’ software. However, in this appendix all software (SW) will be grouped by function, or subsystem: “avionics” (B.1) covers all SW on the avionics TT8 but does not address communication or the control test module in detail; “communications” SW (B.2) includes the communications modules on the avionics Tattletale and all ground station SW; “metrology” includes all SW on the metrology TT8; “control” (B.4) includes specific information on translating control test algorithms to C source code and integrating them into the avionics software.

B.1 Avionics Software and Operating System Overview – MAS (p.1-15) “Avionics software” is the name for the software package loaded to the avionics Tattletale computer. The avionics software is composed of three parts: the initialization section, which establishes vehicle- or system-wide standards (e.g. number of vehicles), mathematical constants, hardware I/O interfaces, and global variables; the main() function, which contains the EMFF operating system (OS); and the many separate functions, or modules, which accomplish specific tasks relating to timing, control, communication, metrology, or computation.

B.1.1 Initialization

B.1.1.1 Version documentation The history of the code should be documented in the top section. CODE_VER is a string established here, available at any point in the code for printout during debugging. Under this are notes regarding sections of the avionics code currently undergoing revision. The version of code to which this document refers is “IT-2A test 3” – or version 3 of Integrated Test 2A.

B.1.1.2 Constants

B.1.1.2.1 System Constants and Data Sizes These constants are important at the entire system level. They set the identification of the local vehicle, the number of vehicles in the system, number of stages in the operating system cycle, buffer sizes for incoming communications and metrology data, and sizes of data-holding vectors (e.g. PVA, MSA). Table B-1 lists system and data size constants and where they are used.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 40 Dept of Aeronautics and Astronautics

Table B-1: Avionics System and Data Size Constants Identifier Name/Description Used in function Default value? VEH_ID Vehicle identification # (0, 1, or 2) MSA, comm code 0 = master NUMBER_OF_VEHICLES Number of vehicles in system MSA, comm code 2 = test 2X TSBUFSIZE Buffer size for TPU channel (input from

Metrology TT8 ) main(): Comm and Met channel initial’n

256 (B)

SBUFSIZE Buffer size for serial channel (comm hardware = DR2000)

main(): comm channel initialization (only)

256 (B)

NUM_OF_STAGES Number of stages in the main OS loop MainTimingInt() 5 for 2-vehicle ops IR_Period Sets control pd for *simulated* IR beacon SetupIRInt() 350 (ms) METRO_RAW_DATA_LENGTH Storage buffer for incoming met data GetMetroData() 100 (B) NUM_MET_DATA_ELEMENTS Sets vector length for collected met data GetMetroData() 12 (elements) NUM_PVA_ELEMENTS Sets vector length for PVA CreateLocal PVA() 9 (elements) NUM_MSA_ELEMENTS Sets vector length for MSA CreateMSA() 13 (elements) RW_PULSE_WIDTH Sets PWM signal width for RW actuation ControlTestcase1(),

SmallControlInterrupt() 0.010 (ms)

C_PULSE_WIDTH Sets PWM signal width for coil actuation ControlTestcase1(), SmallControlInterrupt()

1.0 (ms)

B.1.1.2.2 Sensor and Actuator Calibration Constants The second set of constants pertains to the hardware attached to the avionics TT8. There are hardware-specific calibration constants supplied by the manufacturer for the gyroscope, as well as variables reserved for calibrating input data from avionics sensors (gyro, tachometer) and scaling output data to actuators (reaction wheel, EM coils). There is also a 10^x scalar in this section – x_INTEGER_SCALAR, which is only used to preserve significant figures when converting data to integer variable type. Table B.1.2 lists the sensor and actuator calibration constants and where they are used. Table B-2: Sensor and Actuator Calibration Constants Identifier Name/Description Used in function Default value? GYRO_CAL Gyro-specific calibration value SmallControlInterrupt() 2050 (SN33239), 1987 (SN32846) GYRO_MAX A/D input calibration value SmallControlInterrupt() 4095 (mV) GYRO_MIN A/D input calibration value SmallControlInterrupt() 0 (mV) GYRO_ZERO_MAX Gyro-specific calibration value SmallControlInterrupt() 2055 / 1990 GYRO_ZERO_MIN Gyro-specific calibration value SmallControlInterrupt() 2047 / 1980 COIL_ONE_SENSOR_ZERO Coil current sensor cal - shift SmallControlInterrupt() 0.0 (Amps, placeholder) COIL_TWO_SENSOR_ZERO Coil current sensor cal - shift SmallControlInterrupt() 0.0 (Amps, placeholder) COIL_ONE_ACTUATOR_SCALAR Coil current calibration - scale SmallControlInterrupt() 0.625 (mu Amps, arbitrary) COIL_TWO_ACTUATOR_SCALAR Coil current calibration - scale SmallControlInterrupt() 0.625 (mu Amps, arbitrary) COIL_ONE_ACTUATOR_ZERO Coil current calibration - shift SmallControlInterrupt() 50.0 (Amps, central PWM value) COIL_TWO_ACTUATOR_ZERO Coil current calibration - shift SmallControlInterrupt() 50.0 (Amps, central PWM value) RW_ACTUATOR_SCALAR RWA current calibration - scale SmallControlInterrupt() 20 (no units, 2.6315789 saved?) RW_ACTUATOR_ZERO RWA current calibration - shift SmallControlInterrupt() 50.0 (Amps) COIL_INTEGER_SCALAR Multiplier converting float to int CreateLocalPVA() 100.0 (dimensionless) GYRO_INTEGER_SCALAR Multiplier converting float to int CreateLocalPVA() 10000.0 if rad; 100.0 if deg (d’less)

B.1.1.3 Included Files The EMFF uses Tattletale Model 8 (TT8) with C language capabilities. The avionics code must include certain standard and specialized C source files to run on the TT8. Table B.1.3 lists the standard and Tattletale includes and where they can be found in Tattletale reference documents.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 41 Dept of Aeronautics and Astronautics

Table B-3: Included Files

File name Library Type stdio.h Standard C Math.h Standard C string.h Standard C tt8.h TattleTale Model 8 tt8lib.h TattleTale Model 8 tpu332.h TattleTale Model 8 dio332.h TattleTale Model 8 userio.h TattleTale Model 8 stdlib.h TattleTale Model 8 Time.h TattleTale Model 8

B.1.1.4 Input and Output Channels The input and output (I/O) pins on the TT8 are explained more fully in the avionics hardware section of this document <section 7>. However, the code labels for all I/O pins are defined at the top of the avionics code. Table B.1.4 lists the EMFF TT8 I/O pins with their variable designation and use. Table B-4: I/O Channels

Identifier Name/description TT8 Pin Type and # MET_CHAN Metrology (Tx then Rx) TPU 0 TPU_IR IR beacon timing interrupt count/detection TPU 1 TPU_TACH_DIR Tachometer direction in TPU 2 TPU_TACH Tachometer data in TPU 3 C2_CHAN Coil 2 PWM signal out TPU 4 RW_CHAN RW PWM signal out TPU 5 TPU_ML Main Loop timing interrupt count/detection TPU 6 TPU_ML2 PWM timing signal out TPU 7 C1_CHAN Coil 1 PWM signal out TPU 8 COMM_ICHAN Comm (receive) Serial 14 COMM_OCHAN Comm (transmit) Serial 13 ADCHAN_GYRO Gyro data in (OBSOLETE?) (previously TPU 0) ACTUATOR_STOP OBSOLETE (previously TPU 8)

B.1.1.5 Function Prototypes Each specific task of the avionics software is accomplished in a separate function, or module. Table B.1.5 lists all function names and the purpose of each. For a complete treatment of the avionics software modules, see section B.1.3. Table B-5: Function Prototypes (Avionics Software Modules) Function name Description void SmallControlInterrupt(void) Adjusts attitude control with local feedback between

metrology data arrivals void ControlTestcase1(float MSA[ ]) Executes major control algorithm void SetupMainTimingInt(void) Sets up main loop interrupt (channel and recognition) void MainTimingInt(void) Handler for main timing interrupt; changes to next stage

within OS cycle

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 42 Dept of Aeronautics and Astronautics

void SetupPWM(int TPU_Chan) Sets up a PWM signal on channel TPU_Chan void DefinePWM(int TPU_Chan, float P_width, float

P_duty) Changes attributes of an existing PWM signal

void SetupIRInt(void) Sets up IR beacon interrupt (channel and recognition) void IRInterrupt() Handler for IR beacon interrupt; restarts OS cycle void GetMetroData(unsigned short int metrology_data[]) Brings in new data from metrology TT8 void ClearString(char data[]) Empties a vector of characters void GetT(char cs[]) General; retrieves a byte over TPU channel void GetH(char data[]) General; retrieves byte over serial channel void SendH(char cs[]) General; sends a byte over serial channel void CreateLocalPVA(unsigned short int PVA_Local[],

unsigned short int metrology_data[]) Pulls together local metrology and gyro/coil data into Primary Vehicle Array (PVA)

void Transmit_PVA(unsigned short int PVA_Local[], int PacketNumber, unsigned short int PVA_Local_Packaged)

Packages local PVA for transmission and sends over RF channel through DR2000

void Fetch_PVA(unsigned short int PVA_Remote[], unsigned short int PVA_Remote_Packaged)

Brings in remote PVA from RF channel through DR2000 and unpackages

void CreateMSA(float MSA[], unsigned short PVA_Local[],unsigned short PVA_Remote)

Combines all PVA data into MSA

void FloatToInt(void) Casts a float as an int, saving X significant figures int BitwiseFun(void) Bitwise arithmetic needed to cast float as int void ConvertMSA(float MSA[], int result) Converts the real-number MSA to int form for transmit void InitTACH(void) Initializes tachometer float GetTACH(void) Polls tachometer for data

B.1.1.6 Global Variables EMFF avionics code does use global variables. Global variables are unavoidable when programming the TT8 using interrupts (see section B.1.2 for explanation). Table B.1.6 lists and identifies the avionics global variables and notes the functions that use each. In the avionics software, global variables are grouped according to the functions that use them. NOTE: “unsigned short” implies type int. Table B-6: Global Variables Type Identifier Name/description Used in function(s) Initial value? int flag_cmd N/A 1 int testbit N/A 0 int loop_counter index for OS stage count main, MainTimingInt 0 int loop_stage holds actual OS stage main, MainTimingInt 0 int loop_order [NUM_OF_STAGES] order/numbers of OS stages MainTimingInt 1,2,3,4,5 int stage_length [NUM_OF_STAGES] vector with MainTimingInt

timeout for each OS stage main, MainTimingInt (100,200,300,

400,500) int int_flag interrupt flag main, MainTimingInt 1 int inner_loop_counter gyro calibration counter main 0 int gyro_new_cal gyro calibration value main, SmallControlInterrupt 0 ExcCFrame framebuf0 framebuf1 framebuf2 standard buffers InstallHandler(…) [standard] int Packet_Number packet ID number Transmit_PVA, Fetch_PVA 48 (ASCII A) unsigned short

PVA_Local [NUM_PVA_ELEMENTS] Primary Vehicle Array vector (for comm transmission)

CreateLocalPVA, CreateMSA, Transmit_PVA, Fetch_PVA

N/A

unsigned short

PVA_Remote [NUM_PVA_ELEMENTS] Primary Vehicle Array vector (for comm transmission)

CreateLocalPVA, CreateMSA, Transmit_PVA, Fetch_PVA

N/A

unsigned short

PVA_Local_Packaged [NUM_PVA_ELEMENTS*2]

PVA_Local formatted into bytes for comm trans

Transmit_PVA, Fetch_PVA N/A

unsigned short

PVA_Remote_Packaged [NUM_PVA_ELEMENTS*2]

PVA_Remote formatted into bytes for comm trans

Transmit_PVA, Fetch_PVA N/A

float c_rw_voltage commanded RWA voltage SmallControlInterrupt,

ControlTestcase1 0.0

float cmd_PWM RW cmmanded PWM signal SmallControlInterrupt, ControlTestcase1

N/A

float c_current1 commanded current coil 1 SmallControlInterrupt, ControlTestcase1

0.0

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 43 Dept of Aeronautics and Astronautics

float c_current2 commanded current coil 2 SmallControlInterrupt, ControlTestcase1

0.0

float a_current1 actual current reading coil 1 SmallControlInterrupt, ControlTestcase1

0.0

float a_current2 actual current reading coil 2 SmallControlInterrupt, ControlTestcase1

0.0

float c_torque commanded torque, rad/s SmallControlInterrupt 0 float theta_int theta … radians SmallControlInterrupt 0.0 float theta angle – radians SmallControlInterrupt 0.0 float(?) t_now formerly ulong SmallControlInterrupt 0 float(?) t_last formerly ulong SmallControlInterrupt 0 float(?) dt formerly ulong SmallControlInterrupt 0 float thetadot angular rate - rad/s SmallControlInterrupt 0 float desired_theta_now desired angle, Test 1B only SmallControlInterrupt 0 float desired_theta_last desired angle, Test 1B only SmallControlInterrupt 0 float old_tach smooth out tach data SmallControlInterrupt 0 int all_stop = 1 indicates all actuators off OBSOLETE 0 float num holds element of MSA CreateMSA (?) N/A int sign neg = 1; pos = 0 FloatToInt N/A int mantissa base, float number FloatToInt N/A int exponent exponent, float number FloatToInt N/A

* the “unsigned short int” variable type is necessary for any variable which will be transmitted over the RF channel – that is, which is handled by the comm subsystem. Therefore the PVA data must be formatted such that it can be expressed in type int without losing any significant digits. See B.1.3.14, Create_Local_PVA() for more information on this typecasting and formatting.

B.1.2 Main function and Operating System (OS)

B.1.2.1 Background and Versions The operating system (OS) of the EMFF avionics went through several iterations before it was actually written. We tried to design a simple system with loops and a linear progression, but eventually learned that the tasks the OS had to accomplish were too complex to handle without using interrupts. We also looked at event-based interrupts, which we felt were more appropriate than timing-based interrupts, but found this to be too flaky when used on its own. So the OS that was finally coded, in January 2003, is both timed and event-driven – the driving event is the IR beacon from the metrology system. However, when testing before integration or without metrology, there is another time-based interrupt set to simulate the IR. This is explained in greater detail in the following section (B.1.1.2, OS Interrupt Timing Cycle). For a top-level diagram of the avionics software task progression, see Figure B-1: Overall Avionics Software Flowchart.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 44 Dept of Aeronautics and Astronautics

Figure B-1: Overall Avionics Software Flowchart

The version of code documented in this Appendix is “IT-2A Version 3” – used throughout April and May 2003 on the EMFF vehicle(s). There is some documentation recording the evolution of the code through this version at the top of the C source file. Later versions (as of May 2003 there are “4” and “5”) begin the reorganization of the main code – including simplifying the main thread and deleting extraneous sections and commands as well as streamlining modules. The plan is for versions 4 and 5 of IT-2A to be incorporated into future tests (e.g. IT-2B, 2C, 2D). The specific file to which all examples are referenced in this document is as follows: Metrowerks CodeWarrior Project “Main Project Codev5 2A with MSA test.mcp” … linked at this time to “Main_Code_v3_IT-2A_29APR2003_TEST_modified_for_if_metro_doesnt_work.c” (May 1, 2003. no explanation why the Project version says 5 while the code version is still 3.)

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 45 Dept of Aeronautics and Astronautics

B.1.2.2 OS Interrupt Timing Cycle (overview and design)

B.1.2.2.1 Tasks and Limiting Factors The high-level tasks of the operating system are the following:

1. Collect data on vehicle position/motion (local data) (“Primary Vehicle Array” or PVA) 2. Communicate local data to other vehicles and gather remote data from other vehicles 3. Combine all data into Master State Array (MSA) 4. Run control algorithm on MSA data 5. Implement output from control algorithm by commanding actuators (coils and reaction

wheel) All of the above tasks must happen in a single cycle of the OS. There are two main limiting factors on length of the OS cycle: the frequency of updates required to run the control algorithm successfully (high end) and the rate at which metrology can supply new data (low end). The speed of the computer is not a limiting factor; when using interrupts, the CPU and TPU capacity is more than sufficient to run at the speed required by control. The speed of the communication subsystem (transmission over the RF channel among multiple vehicles and a ground station) is also a factor, but the communication subsystem is not fully implemented in the code documented here, so its limits are not yet certain. For more on comm, see section 2 in this Appendix.

B.1.2.2.2 Stage Progression The avionics software main function is broken up into stages. Theoretically, each high-level task in the OS is addressed in one stage of the function. The time allotted to complete each stage is determined by an “inner loop” interrupt. The timing of the interrupt is determined by the global integer variable stage_length[NUM_OF_STAGES] – defined at the top of the code as a vector containing the length of each OS stage in milliseconds. If any one high-level task times out, the OS proceeds to the next stage. For example, if there is an error bringing in metrology data, rather than waste time (causing further drift) the OS will proceed through the stages anyway, and extrapolate the control input at the final stage using metrology data from the previous cycle.

B.1.2.2.3 Infrared Interrupt To optimize accuracy, the five stages of the OS should run every time fresh local data is available from the metrology subsystem. Therefore the system timing is driven by an interrupt based on the infrared (IR) beacon flash from the metrology Tattletale (TT8), which signals a new metrology data-gathering cycle. The input pin through which avionics TT8 receives the IR signal from metrology TT8 is TPU channel 1.

B.1.2.2.4 Simulated IR The avionics TT8 is also set up to run a simulated IR interrupt when the metrology subsystem is not available or when debugging the avionics subsystem in an isolated environment. The standard simulated IR cycle length is defined to be 350ms (#define IR_Period, see Table 1) but may be adjusted according to need while testing.

B.1.2.2.5 Intermediate Adjustments – Small Control Loop

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 46 Dept of Aeronautics and Astronautics

Since the main loop is set to run on the order of <5Hz based on the metrology subsystem, there is a substantial amount of time for drift to occur between arrivals of fresh metrology data. To ensure that the system does not drift beyond the point of recovery, more frequent adjustments are made to local vehicle control using measurements taken from the gyroscope on board each vehicle. This “Small Control Loop” (SCL) is run on a timed interrupt approximately every 100 ms. For sequence and details of the SCL, refer to section 1.3 (Modules), under SmallControlInterrupt().

B.1.2.2.6 Summary of Timing Design The process developed in January 2003 approximately follows the overall timing cycle shown in Figure B-2.

Figure B-2: Operating System Timing Cycle

For a short time at each SCL interrupt the processor executes attitude adjustments using the gyro data. metrology data collection, RF communication, and main control execution all occur at each IR interrupt. NOTE: In reality the period on the SCL is not exactly 100ms; therefore there is no simultaneous interrupt at multiples of 700ms.

B.1.2.3 OS Implementation: main() Function and Interrupts When the avionics TT8 is powered up, it runs through the avionics initialization code (B.1.1) and then enters the OS proper in the main() function. (see Figure B-1 in section B.1.2.1). The main() function contains initialization of all interrupts (IR, main timing, and small control loop), hardware, pulse width modulated (PWM) signals, and data arrays.

B.1.2.3.1 OS Initialization Figure B-3 follows the thread of operations in the main() function through this initialization process and the entrance to the OS loop.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 47 Dept of Aeronautics and Astronautics

Figure B-3: OS Initialization Sequence

B.1.2.3.2 Create and Initialize Local Variables Aside from the global variables noted in section B.1.1.6 (Table B-6), the avionics code utilizes many variables local to the main function. Table B-7 lists the local main() function variables and their significance. Table B-7: Local Variables, main() Function Type* Identifier Name/description Initial value? float cal_loop counter for gyro calibration loop 2 int temp_cal_var used in gyro calibration - int i loop counter – PVA debug 0 unsigned char done exit condition for main loop 0 char data[257] debug for comm – OBSOLETE NULL int met_stillopen test MET_CHAN close Tx - before reopen Rx 1 unsigned short int metrology_data

[NUM_MET_DATA_ELEMENTS] vector to hold incoming metrology data 0

unsigned short int PVA_Local

[NUM_PVA_ELEMENTS]

holds PVA data for local vehicle (1, or A) 0

unsigned short int PVA_Remote [NUM_PVA_ELEMENTS]

holds PVA data for remote vehicle (2, or B) 0

unsigned short int PVA_C[NUM_PVA_ELEMENTS] holds PVA data for third vehicle - FUTURE 0 float MSA[NUM_MSA_ELEMENTS] holds MSA information for ControlTestcase1 0 int result called by ConvertMSA(MSA, result) 0 long sammy holds TPU TCR 1 clock value; type long required by

TT8 function TPUGetTCR1() -

int result1, result2 comm initialization – channel open success -

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 48 Dept of Aeronautics and Astronautics

* the “unsigned short int” variable type is necessary for any variable which will be transmitted over the RF channel – that is, which is handled by the comm subsystem. Therefore the PVA data must be formatted such that it can be expressed in type int without losing any significant digits. See B.1.3.14 (Create_Local_PVA()) for more information on this typecasting and formatting.

B.1.2.3.3 Print ID info When running the avionics TT8 from Motocross (loading program), it will print identification information at the beginning of every run. It prints the title of the code (not filename), version number as defined in the label at the top of the file, and the time/date of the last compilation.

B.1.2.3.4 TPU clock The temporary variable “sammy” holds the value returned here from TPUGetTCR1(). More information on this function can be found in the Tattletale Model 8 manual, ANSI-C version, found online as “TT8C_Man.pdf” in \\aero-astro\CDIO3\07. Reference\4. Tattletale Manual\ .

B.1.2.3.5 IR Interrupt Handler Defining the infrared interrupt includes three function calls: setting up the interrupt, installing the interrupt handler, and enabling the interrupt. Details about how to use each of these functions can be found in the text(s) referenced for each function. - SetupIRInt() Reference: section B.1.3.6 (SetupIRInt) NOTE: The period of the *simulated* IR interrupt (PWM count) is set in this function. - InstallHandler(IRInterrupt, TPU_INT_VECTOR + TPU_IR, &framebuf2) References: TT8C_Man.pdf, section 5 page 17 (InstallHandler) section B.1.3.7 (IRInterrupt) - TPUInterruptEnable(TPU_IR) Reference: TT8C_Man.pdf, section 5 page 42

B.1.2.3.6 Set up actuator PWM outputs The system actuators (reaction wheel and two superconducting coils) are commanded by the control algorithm using a pulse-width modulated (PWM) signal – which is put out through the avionics TT8. Refer to section 1.3.x (SetupPWM) for more detailed information. The PWM signal itself is monitored by the TT8 TPU – for more information on this process, see the specific TPU reference manual “tpupn17 – PWM Function.pdf” in \\aero-astro\CDIO3\07. Reference\4. Tattletale Manual\App Notes\ .

B.1.2.3.7 Initialize RW PWM The reaction wheel PWM signal is specifically initialized to a 50% duty cycle immediately after the channel is set up. This is the “zero” setting for the reaction wheel. It is this opinion of this EMFFORCER that there should also be initialization commands to re-define the PWM for each coil – and that since we had not yet powered up the coils at this version of the test we had not included those commands. However, please note that this is speculation.

B.1.2.3.8 Initialize Tachometer

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 49 Dept of Aeronautics and Astronautics

Simply calls the InitTACH() function. For more information refer to B.1.3.x (InitTACH).

B.1.2.3.9 Calibrate gyroscope The gyroscope is calibrated by running a 90-rep loop that incorporates the new value into the old values. It changes the global variable gyro_new_cal using the local variables temp_cal_var and cal_loop. For details on the function used to access the gyro reading), refer to TT8C_Man.pdf, section 5, page 10 (AtoDReadMilliVolts).

B.1.2.3.10 Define PITR timer (Small Control Loop) The Small Control Loop (SCL) runs on an interrupt different from that which governs the Main Timing and Infrared interrupts. The periodic interrupt timer (PITR) is an ultra-fast timer available on the TT8 which runs separately from the main thread. Since the SCL must interrupt with the highest frequency, it is set using this timer. The PITR is mentioned on pages 6-20 and 5-17 in TT8C_Man.pdf.

B.1.2.3.11 Set Up Main Timing Interrupt The Main Loop (ML) Timing Interrupt governs the length of each stage of the OS. Functions used to set up the - SetupMainTimingInt() Reference: section B.1.3.x (SetupMainTimingInt) NOTE: The *counter* PWM signal is started in this function. We set a signal to fire every millisecond through pin TPU_ML2, and tie that pin to TPU_ML – through which we count the pulses, thereby incrementing the timer for the Main Timing and *simulated* IR interrupts. - InstallHandler(MainTimingInt, TPU_INT_VECTOR + TPU_ML, &framebuf1) References: TT8C_Man.pdf, section 5 page 17 (InstallHandler) section B.1.3.x (MainTimingInt) NOTE: This set-up sequence does *not* call “TPUInterruptEnable(TPU_ML)” – because that function is called already in MainTimingInt(). The interrupt timeout length (i.e. number of pulses counted before int_flag is set) on TPU_ML is set differently depending on which stage the OS is in – governed by the global variable stage_length(5).

B.1.2.3.12 Initialize Main Timing Interrupt After setting up the main timing interrupt, it is necessary to begin the sequence by running the handler: MainTimingInt(). This does the following: - increments global variable loop_counter (from 0, as it was initialized, to 1) - sets MainTimingInt timer to stage_length[loop_counter] (stage_length[1] = 100ms) - sets int_flag = 1 (TRUE) When MainTimingInt() returns, the remainder of the initialization process does the following: - sets int_flag = 1 (TRUE) (again) - resets loop_counter = 0 (for entrance into main loop?)

B.1.2.3.13 Initialize Communications I/O Comm I/O initialization includes the following processes: - Open transmit channel – TSerOpen(COMM_OCHAN, …) – with error message

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 50 Dept of Aeronautics and Astronautics

Reference: TT8C_Man.pdf, section 5 page 44 (TSerOpen) - Open receive channel - TSerOpen(COMM_ICHAN, …) – with error message Reference: TT8C_Man.pdf, section 5 page 44 (TSerOpen) - Provide buffer for incoming comm data (Serial input) Reference: TT8C_Man.pdf, section 5 page 31 (SerSetInBuf)

B.1.2.3.14 Initialize Metrology I/O Metrology I/O initialization includes the following processes: - Open TT8-TT8 channel to *transmit* - TSerOpen(MET_CHAN, …, OUTP, …) Reference: TT8C_Man.pdf, section 5 page 44 (TSerOpen) - Send initializing “start byte” to metrology TT8 – “go” command (doesn’t currently work) Reference: TT8C_Man.pdf, section 5 page 45 (TSerPutByte) - Close transmit channel – with error message – TSerClose(MET_CHAN) Reference: TT8C_Man.pdf, section 5 page 43 (TSerClose) - Open TT8-TT8 channel to *receive* - TSerOpen(MET_CHAN, …, INP, …) Reference: TT8C_Man.pdf, section 5 page 44 (TSerOpen) - Flush metrology input channel to clear out any junk accumulated on initialization Reference: TT8C_Man.pdf, section 5 page 43 (TSerInFlush)

B.1.2.3.15 Initialize Data Arrays This sequence ensures that the Primary Vehicle Array (PVA) data are set to 0 before they are used in the main loop. The arrays currently initialized here are those used by the comm sequence for vehicle 1 in a two-node network (what we have): PVA_Local, PVA_Remote, PVA_Local_Packaged, PVA_Remote_Packaged. The “–Packaged” arrays are the original arrays (unsigned short integer, 2 bytes per element) split into bytes for transmission to the comm hardware (DR2000) and over the RF channel.

B.1.2.3.16 Start Avionics Local Timer The PVA data requires a local timestamp in order to link data for the local vehicle (PVA_Local) to the simultaneously collected set of data from other vehicle(s) (PVA_Remote). This is achieved through the TT8 embedded “stopwatch” function. For more information, refer to TT8C_Man.pdf, section 5 page 38 (StopWatchStart()).

B.1.2.3.17 Enter Main Loop The next step is to enter the Main Loop – set apart by a “while” loop with exit condition of a keystroke. The main loop is explained in detail in the following section, B.1.2.

B.1.2.3.18 OS Main Loop and Interrupts Figure B-4 traces the flow of the OS Main Loop *without* the Small Control Loop interrupts. The SCL runs separately on its PITR (periodic interrupt timer) at a higher frequency of interrupt. For more information on the SCL, see its module description (B.1.3.x, SmallControlInterrupt).

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 51 Dept of Aeronautics and Astronautics

Figure B-4: OS Main Loop Cycle

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 52 Dept of Aeronautics and Astronautics

B.1.2.3.19 Enter Main Loop The “Main Loop” cycle of the OS – containing the functions leading up to execution of the control algorithm – is set apart inside a simple “while” loop. Until the exit condition is met (done = 1), the OS continues to address interrupts and cycle through the stages.

B.1.2.3.20 Main Loop Exit Condition The exit condition for the main loop is detection of a keyboard hit (reference TT8C_Man.pdf section 5 page 18, kbhit()) – but this can only register while testing the avionics code through a serial cable to a host PC running Motocross (the TT8 loading program). When testing the avionics code as burned to FLASH memory and disconnected from the PC, the only exit is to manually reset the TT8 by pressing its [orange] reset button or cutting power.

B.1.2.3.21 The Variable int_flag The global variable int_flag (interrupt flag) triggers entry into the main() function switch/case statement, which contains the OS stages in sequence. Int_flag is… - INITIALIZED to 1 at the top of the avionics code - SET to 1 in MainTimingInt, which runs both whenever the main timer (on TPU_ML) interrupts, or when IRInterrupt runs (when there is an IR beacon flash, or the simulated-IR timer on TPU_IR interrupts; IRInterrupt calls MainTimingInt) - CLEARED (set to 0) in the main function, immediately after recognition that it was set.

B.1.2.3.22 The Variables Loop_Stage and Loop_counter The global variable loop_stage determines which task in the OS cycle is executed next. After clearing int_flag, the next action is to assign a value to loop_stage based on the current value of the variable loop_counter. The global variable loop_counter holds the *index* of the current OS stage. The range of this index is 0-4. Loop_counter is an index of two vectors: - the current stage number (e.g. 3)

- set of stage numbers is held in the global variable vector loop_order - range of stage numbers is 1 to 5 - stage number = loop_counter + 1

- the length of time (e.g. 150) allotted for that stage (e.g. 3) before the main timer interrupts - set of time lengths is held in the global variable vector stage_length, in milliseconds

B.1.2.3.23 OS Stage 1 – Wait In the case that the stage number is 1 (this means that loop_counter = 0), the only task of the OS is to wait until it receives metrology data. It appears that this stage is left over from a time when the OS cycle restart was to be triggered by the arrival of data from the metrology TT8. Regardless, the avionics system does nothing in this case and returns to the beginning of the main OS loop (while(!done)) to check done and int_flag again. NOTE: If the main timer interrupts before the process is complete, an error message is printed to the screen (when working while connected to a PC running Motocross).

B.1.2.3.24 OS Stage 2 – Metrology

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 53 Dept of Aeronautics and Astronautics

When the stage number is 2 (loop_counter = 1), the OS checks for metrology data. This calls the following steps: - Check to see if the data arrived, i.e., if there is a data byte waiting on the metrology channel Reference: TT8C_Man.pdf, section 5 page 42 (TSerByteAvail(MET_CHAN)) - If no data have arrived, print error to screen (only when connected to PC with Motocross) - If data are there, bring in the data using GetMetroData(metrology_data). References: section B.1.3.11 (GetMetroData(metrology_data[])) section B.1.3.12 (GetT(data[])) TT8C_Man.pdf, section 5 page 43 (TSerGetByte()) - Return to beginning of main loop; check done and int_flag NOTE: If the main timer interrupts before the process is complete, an error message is printed to the screen (when working while connected to a PC running Motocross).

B.1.2.3.25 OS Stage 3 – PVA When the stage number is 3 (loop_counter = 2), the avionics TT8 must collect a local timestamp, local gyro and tach readings, and the metrology data collected in stage 2; then it must format this data into unsigned short int type and enter into the PVA_Local vector. The reason for the uniform typecasting is to prepare the data for transmission over the RF channel in the communication process.

Reference: section B.1.3.14 (CreateLocalPVA(PVA_Local[])) After this, follow the same procedure: return to beginning of main loop; check done and int_flag NOTE: If the main timer interrupts before the process is complete, an error message is printed to the screen (when working while connected to a PC running Motocross).

B.1.2.3.26 OS Stage 4 - Comm When the stage number is 4 (loop_counter = 3), the avionics TT8 enters the communication process. For the two-node network (one vehicle + ground station (GS), RF transmission from vehicle to GS only), this is simple; there is - one conditional statement that checks the vehicle ID (if VEH_ID == 0), and proceeds to… - transmit or receive accordingly. For a multi-vehicle network, the communication algorithm and code is substantially more complex; for more comm theory and design refer to section B.2 (Communication Software). References: section B.1.3.17 (Transmit_PVA(PVA_Local[], …)) After this, follow the same procedure: return to beginning of main loop; check done and int_flag NOTE: If the main timer interrupts before the process is complete, an error message is printed to the screen (when working connected to a PC running Motocross).

B.1.2.3.27 OS Stage 5 - MSA and Control When the stage number is 5 (loop_counter = 4), the avionics TT8 must run two related processes sequentially: - create the Master State Array (MSA) Reference: sec B.1.3.19 (CreateMSA(MSA[], PVA_Local[], PVA_Remote[])) - run the control test case using that MSA. Reference: Appendix A: Control NOTE1: For an expanded system, the comm would handle and log an MSA transmission to the ground station (GS) as well as the PVA transmission sequence. To prepare the MSA for this

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 54 Dept of Aeronautics and Astronautics

transmission, it must be typecast all as unsigned short int – which is accomplished through ConvertMSA(MSA[], result). However, this code has not yet been tested on the floor. NOTE2: If the main timer interrupts before the process is complete, an error message is printed to the screen (when working connected to a PC running Motocross).

B.1.3 Avionics Software: Modules

B.1.3.1 SmallControlInterrupt NOTE: ALL I/O for the Small Control Interrupt (SCL) is GLOBAL because the function is an interrupt handler, which cannot be passed any inputs or return any values. Global Variables - Inputs: determined in overall control calculations and only referenced here

c_speed (commanded RW speed), c_current1, c_current2 (commanded current for coils)

Global Variables – Inputs/Outputs (modified): a_current1, a_current2 (actual current value in coil 1 or 2) Other references: TT8 library function AtoDReadMillivolts(ADCHAN_x) (TT8C_Man.pdf section 5) EMFF function GetTACH() (section B.1.3.9) TT8 function StopWatchTime() (TT8C_Man.pdf section 5) Gyro calibration variables and procedures (refer to B.1.2, B.1.1) DefinePWM(inputs) (B.1.3.5) Defined channels for signal output to each actuator (RW, coil1 coil 2) (see B.1.1) Notes:

The Small Control Loop interrupts the OS system progress approximately every 100ms (based on the PITR timer set in the main() function) to collect data on the actuators and compensate for drift in control due to time lag. It…

- gathers fresh gyroscope and tachometer data with the most recent (but older than gyro/tach) desired actuation levels commanded by control.

- adjusts the PWM signal put out to the actuators, compensating for control/position drift as well as for weakening batteries powering the coils/RW.

This function is extremely well commented. See source file (“Main_Code_v3_IT-2A_20APR2003_TEST_modified_for_if_metro_doesnt_work.c”)

for a detailed walkthrough and step-by-step explanation of SCL calculations and commands. The StopWatchTime function returns the time in microseconds in variable type ulong,

but we have changed it temporarily to type float for debugging The coil current sensors are not operational at print time for this document; code involving commanded and actual coil current has not been adequately (at all?) tested/debugged

B.1.3.2 ControlTestCase1 <BB> The purpose of this section is to control the vehicle. This section is referred to as the big control loop because it is where the overall control is calculated. It differs from the small control loop because it updates slower and uses metrology position/attitude data in addition to local gyro and tachometer feedback data. First this modules stores all the MSA data into an array. It then set up some counters, constants, and variables. The most important of these are control_output, input_state, and gains.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 55 Dept of Aeronautics and Astronautics

The array control_output is the output command of the controller. The array has three values for test case 2ab. The first value is the commanded magnetic moment, mu, for coil 0 -- the coil that starts parallel to the fixed coil, the big coil. The second value is the commanded magnetic moment for the other coil, and the last value is the commanded torque for the reaction wheel. The input_state array contains six values which are computed from the MSA values mentioned above. The first value is the x distance between the vehicles, the second value is the y distance, and the third value is theta. The last three values are the derivatives of the first three. For more detail on this see the modeling section of Appendix A. The gains matrix is a matrix that is the size of control_output by the size of input_state, in this case 3 by 6. These values are taken from the Control team’s work and constitute the core of the controller for the system. For more information see Appendix A. The next part of this module performs a matrix multiplication of the gains matrix and the input_state array. The results of this multiplication is stored in control_output. The values of control_output are then manipulated to provide commanded current to the coils -- c_current1 and c_current2 – and commanded voltage to the reaction wheel. The conversions for c_current1 and c_current2 are straightforward. The conversion for c_torque is a bit more tricky and is dealt with in Appendix A.

B.1.3.3 MainTimingInt Inputs: none Outputs/Return: none Global variables accessed: loop_counter, int_flag, stage_length[] Other references: TPU_ML (main loop timing/interrupt pin), Processes:

Increment loop_counter Clear the interrupt on TPU_ML Set the number of counts TPU_ML should register before next interrupt set number of counts = stage_length[loop_counter] Initialize TPU_ML to begin counting again Reset int_flag = 1 Conditional: if this process has run the last stage (loop_counter == NUM_OF_STAGES),

then the main loop has completed a full cycle before registering an IR interrupt. At this point the TT8 should reset and begin again; instead for debugging purposes simply reset loop_counter to 0 (to restart the OS cycle).

Notes: Called as handler for TPU_ML timeout interrupt; *also* called from IRInterrupt (handler

for TPU_IR interrupt, which happens either from metrology IR or from simulated IR PWM). The IR-simulation PWM signal is set up and defined at the beginning of the

MainTimingInt() module; this code should be commented out when running the avionics with metrology connected.

B.1.3.4 SetupPWM Inputs: int TPU_Chan Outputs/Return: none Global variables accessed: none Other references: TPU function: PWM “tpupn17 - PWM Function.pdf” in TT8 App Notes

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 56 Dept of Aeronautics and Astronautics

Processes: Uses process as defined in Motorola spec sheets to set up a pulse width-modulated function going out on channel “TPU_Chan” with given period length and duty cycle.

Notes: Refer to TT8 app notes for more information on function setup and PRAM offsets.

B.1.3.5 DefinePWM Inputs: int TPU_Chan, float P_width (milliseconds), float P_duty (percent 0 100) Outputs/Return: none Global variables accessed: none Other references: TPU function: PWM “tpupn17 - PWM Function.pdf” in TT8 App Notes Processes:

Prints PWM change information to the screen (if hooked to PC running Motocross) Conditional: IF NEW PWM DOWN TIME IS LESS THAN 10 ms set new pulse width and percent duty using TPU PWM function ELSE print error message!

Notes: the error message from a down time of *greater* than 10 ms is to limit the *upper* end of the PWM signal. There is a maximum time that you can set the pulse width (0x8000 [hex]) - duty cycle combination, and the conditional checks that.

B.1.3.6 SetupIRInt This function sets up the infrared interrupt receiver (NOT the interrupt handler!) Inputs: none Outputs: none Global variables accessed: none Other references:

TPU_IR (pin detecting incoming interrupt) IR_Period (defined length for simulated IR pulse) TPU function: ITC “tpupn16 - ITC Function.pdf” in TT8 App Notes

Processes: Uses process as defined in Motorola spec sheets to receive an incoming pulse and register as an interrupt. Basically: disable chan (TPU_IR) set function parameters enable chan. Notes: Refer to TT8 app notes for more information on function setup and PRAM offsets.

B.1.3.7 IRInterrupt This function is the handler for the incoming IR beacon interrupt. Inputs: none Outputs: none Global variables accessed: loop_counter Other references:

TPU_IR (pin detecting incoming IR or simulated IR interrupt) TPU_ML (main loop timing/interrupt pin – timeout varies according to OS stage), MainTimingInt(); (section B.1.3.3) TPUSetInterrupt(channel); TT8 library function, TT8C_Man.pdf sec 5 page 40 TPU_InterruptEnable(channel); TT8 library function, TT8C_Man.pdf sec 5 page 42

Processes: Clear IR interrupt and disable it to reset

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 57 Dept of Aeronautics and Astronautics

Reset “loop_counter” to -1. Necessary because the first action in MainTimingInt is to increment loop_counter - since loop_counter is an index it must first refer to the “0th loop.”

Call MainTimingInt(); which begins the OS cycle at stage 1 (index 0) Re-enable the IR interrupt

Notes: none

B.1.3.8 InitTACH Inputs: none Outputs: none Global variables accessed: none Other references:

TPU_TACH (digital I/O pin receiving signal/data from tachometer) TPU function: FQM “tpupn03 - FQM Function.pdf” in TT8 App Notes

Processes: Uses process as defined in Motorola spec sheets to detect and translate signal coming in over pin TPU_TACH. Defines recognition of signal, initializes and enables channel.

Notes: Refer to TT8 app notes for more information on function setup and PRAM offsets.

B.1.3.9 GetTACH Inputs: none Outputs: returns type float (tach reading) Global variables accessed: old_tach (RW speed detected on previous cycle) Local variables: float speed (speed of RW - init to 0.0); int dir (direction of RW spin) Other references: TPUGetPin(channel); TT8 library fuction, TT8C_Man.pdf sec 5 page 41

TPU_TACH (digital I/O pin receiving signal/data from tachometer) TPU_TACH_DIR (digital I/O pin receiving *direction* data from tachometer)

Processes: Note direction of RW (read TPU_TACH_DIR)

Read TPU_TACH and convert to RPM or rad/second Smooth data - avg with last tach reading (old_tach) Return new calculated RW speed as type float.

Notes: none

B.1.3.10 GetMetroData Inputs: unsigned short int metrology_data[] Outputs/Return: (modify metrology_data[]) Global variables accessed: metrology_data[] duplicate array in global/local; unresolved!! Local variables: raw_data[], int loop (init to 0), numofloop Other references: GetT() function called to pull in bytes from pin; strlen() C library function Processes: Initialize raw data holding array, loop vars Call incoming-data function, GetT. (fills raw data array with bytes) Converts bytes (char-type elements) of raw data into words (short int), metrology_data[] Does this through a loop that combines every two elements of raw_data into one of metrology_data; use “8-bit shift” left to hold places; then express bitwise #as decimal for int.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 58 Dept of Aeronautics and Astronautics

Notes: Sec. B.1.3.10 describes how this modules *should* proceed. In fact, at time of print, this version of the code has been modified to work without incoming metrology data – so instead of using this function to call GetT and work with a data stream off the MET_CHAN TPU pin, we set the elements of metrology_data[] to initial values and checked that these values came through avionics/comm. correctly during initial debugging of IT-2A.

B.1.3.11 GetT Inputs: char data[] (uses this because data coming across pin is 1 byte at a time) Outputs: (modified raw_data) Global variables accessed: none Other references: TSerByteAvail and TSerGetByte (TT8C_Man.pdf, section 5) Processes: Use the TT8 library functions to pull the bytes coming across the metrology-avionics TT8 connection (MET_CHAN = TPU pin number). Fills raw data array with as many bytes as are available. Flushes input at completion (detects no more bytes available). Notes: This is a reusable function called currently only by GetMetroData

B.1.3.12 ClearString Inputs: char data[] Outputs: (modified data[]) Global variables accessed none: Other references: C library function strlen(array[]) (return string length of array of type char) Processes: Empties the string data[] - sets all elements to NULL. Notes: This is a reusable function. Currently *should* be called by GetMetroData to prevent excess old data from interfering with new measurements. In fact it is not used...

B.1.3.13 CreateLocalPVA - get a timestamp (based on the stopwatch timer started just before entering this mail loop) Reference: TT8C_Man.pdf section 5 page 38 (StopWatchTime()) - read in local attitude/rate and feedback data from the gyro and tach (hardware local to avionics board, not connected to metrology TT8). Reference: - convert all variables to the same accepted format (unsigned short int, in preparation for comm transmission); this is difficult because the timestamp access function returns an unsigned long-type value, and the gyro-read function returns a float-type value. - enter the timestamp, metrology data and local attitude/rate data into the PVA (PVA_Local).

B.1.3.14 SendH Inputs: char cs[] Outputs: (array *not* modified) Global variables accessed: none Other references: SerPutByte = get byte off serial line (in TT8_Man.c section 5) Processes: Use TT8 library function SerPutByte to transmit a single byte over the *serial* channel, the avionics output to the DR2000 communication hardware (hence send”H”).

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 59 Dept of Aeronautics and Astronautics

Notes: There is some confusion over data transmission. If you try to send more than 1 byte at a time, it appears that anything past the first byte is lost (ie.not put on the hardware for transmission),

B.1.3.15 GetH Inputs: char data[] Outputs: (modified data[]) Global variables accessed: none Other references: SerByteAvail, SerGetByte (see SendH descriptions & sec 5 of TT8C_Man.pdf) Processes: Checks to see if a byte is available on the serial channel; then brings it in and stores in raw data array. Notes: see SendH for complementary function.

B.1.3.16 Transmit_PVA For information on this communication function, see section B.2 Communication Software. NOTE: This replaces the baseline function SendH, which contained no comm. code.

B.1.3.17 Fetch_PVA For information on this communication function, see section B.2 Communication Software. NOTE: This replaces the baseline function GetH, which contained no comm. code.

B.1.3.18 CreateMSA <SJS & MAS> Variables: float MSA[], unsigned short PVA_Local[], unsigned short PVA_Remote[]. Processes:

Converts the raw data from PVA_Local[] and PVA_Remote[] from the raw unsigned short data to float.

Check function: ensure that the PVA distances are accurate. Previous MSA’s velocities are taken Multiply those by dt. Whichever PVA distance is closer is chosen for the MSA

Notes: Table B-X lists the elements in float MSA(13): Table B-8: Elements in the Master State Array (MSA)

MSA[i] Function

MSA[0] timestamp for MSA creation

MSA[1] x position of vehicle 0

MSA[2] x velocity of vehicle 0

MSA[3] y position of vehicle 0

MSA[4] y velocity of vehicle 0

MSA[5] angle of zero vehicle axis with respect to 0 veh axis --> frame of reference

MSA[6] vehicle 0 rate (gyro measurement)

MSA[7] x position of vehicle 1 MSA[8] x velocity of vehicle 1

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 60 Dept of Aeronautics and Astronautics

MSA[9] y position of vehicle 1

MSA[10] y velocity of vehicle 1

MSA[11] angle of 1veh axis with respect to 0 vehicle axis

MSA[12] vehicle 1 rate (gyro measurement)

Local variables used (type float):

MSA_time, MSA_x0, MSA_y0, MSA_x0dot, MSA_y0dot, MSA_ang01, MSA_ang0dot, MSA_x1, MSA_y1, MSA_x1dot, MSA_y1dot,

MSA_ang10, MSA_ang1dot, MSA_ang00, dt, dx1, dy1, MSAdist0, MSAdist1, Diff_PVA_MSA0, Diff_PVA_MSA1, PVA_sec,

PVAmsec_raw, PVAmsec, PVA0_met_time, PVA0_ang1, PVA0_dist1, rategyro0, rategyro1, PVA1_dist0, PVA1_ang10.

Notes: The digits 1 or 0 in (e.g.) PVA1_ang10 imply the angle ccw *from* one vehicle (0 = master or central (NOT necessarily local), 1 = removed (base coordinates are non-zero).

B.1.3.19 FloatToInt <SJS> Inputs: none Outputs/Return: none Global variables accesses: none Internal variables: int counter, flag, intvar; float var; Processes:

Takes a float value, and converts it to a value that can be read as an int. Determines if the value is positive or negative. Creates the variable int intvar, which is simply the truncated value of the MSA[]

reference value. Includes if( ) statements for all the different possible orders of magnitude and breaks

down the float value into mantissa and exponent. The float value is converted into a string of sixteen bits where the first number is the sign

of the value (1 for negative, 0 positive), the next twelve for the mantissa, and the last three for the exponent.

B.1.3.20 BitwiseFun <SJS> Inputs: none Outputs: none Global variables accessed: none Internal variables: int first_half, second_half, result; Other references: none

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 61 Dept of Aeronautics and Astronautics

Processes: Bitwise arithmetic is performed to convert the float value into a string of sixteen bits where the first number is the sign of the value (1 for negative, 0 positive), the next twelve for the mantissa, and the last three for the exponent. Notes: none

B.1.3.21 ConvertMSA <SJS> Inputs: float MSA[]; int result; Outputs/Return: float MSA[]; Global variables accessed: none Local variables: int IntMSA[], int i; Other references: none Processes: Takes each float value in MSA[] and converts it into a string of 16 bits by calling the

functions FloatToInt() followed by BitwiseFun(). Notes: none

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 62 Dept of Aeronautics and Astronautics

B.2 Communications Software (JEU)

B.2.1 Packet Structure The DR2000 Protocol Packet definition sets the overarching construction of the communications system packet structure. The DR2000 Protocol, shown in Table B.2-A, defines the packet header, the declaration and allocation of data bytes, and the use of built-in error checking and correction routines. The communications team created a virtual network layer for integration of the DR2000 technology directly into the EMFFORCE project. This layer constructs a system specific network using secondary headers and TDMA (Time Division Multiple Access)-like timeslots to enhance the packet definitions hardwired into the DR2000s.

Table B.2-A: DR2000 Protocol Packet Definition (courtesy of the RFM DR2000 Manual)

Primary Packet Header Data Error Checking To Address From Address Packet Number Command Length Data Frame Check 1 Frame Check 2

1 Byte 1 Byte 1 Byte 1 Byte 1 Byte n Bytes 1 Byte 1 Byte 0-255 1-255 1-255 3-239 1-255 0-255 0-255 0-255

B.2.1.1 Header The primary packet header contains information used by the DR2000 communications transceiver. As per DR2000 Protocol specifications, the packet header contains:

• To Address (one byte) • From Address (one byte) • Packet Number (one byte) • Command (one byte) • Length (one byte)

For reference, the node assignments for our system are as follows:

• 0x31 Node 1: GUI Ground Station • 0x32 Node 2: Vehicle 0 • 0x33 Node 3: Vehicle 1 • 0x34 Node 4: Vehicle 2

To Address: The “To Address” tells the DR2000 transceiver which node in the network to transmit to. The hex value of ‘0x00’ instructs the receiver to broadcast the packet to all nodes in the network. To transmit to a single node, this value should be set to the hex value representing that node. For example, in our system the hex value ‘0x31’ represents node 1 (also ASCII character value ‘1’). This value is automatically stored in the flash memory of the DR2000.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 63 Dept of Aeronautics and Astronautics

From Address: The “From Address” tells the other nodes which node in the network sent the packet. Once again, the value must be in hex, with the same rules regarding the address values applying except for the broadcast value (a “From” broadcast is meaningless). The “From Address” value also is automatically stored in the flash memory of the DR2000.

Packet Number: The “Packet Number” header exists for two main reasons. First, it allows the application layer in the network to keep track of packets emanating from one source. Second, it allows the error-checking and correction software to request a repeat of a packet if necessary (the DR2000 supposedly makes use of an Automatic Repeat Request error-correction routine). Our system uses packet numbers with decimal values ranging from 48 (ASCII character ‘0’) to 57 (ASCII character ‘9’). These packet numbers recycle every ten packets.

Command: The “Command” value is currently set at 0x40. The actual function of the “Command” has not been determined. However, it could be used to transmit additional information about the packet (similar to a secondary header) as long as the software is adjusted to interpret the “Command” header. This may run into problems in the GUI since it uses a specific byte sequence to capture the desired information.

Length: The “Length” allocates the number of bytes used for the transmitted data. This value needs to be consistent with the flash packet size required by the DR2000.

NOTE: The flash packet size is the data length plus 5 (for the header).

B.2.1.2 Secondary headers Secondary headers provide the functionality of a primary packet header (Please see the section on the packet header) but are contained within the body of the packet (data bytes). They are often used to provide information concerning the packet in addition to what is provided in the primary header. They are particularly useful for transmitting information about how the data should be interpreted or decoded.

The current system has a single secondary header that is used by the GUI to decide what information it should record. This header consists of a two-byte sequence of the ASCII character ‘6’ (54 decimal). When coded, the secondary header appears as:

TSerPutByte(OCHAN, 54); TSerPutByte(OCHAN, 54);

When a packet enters the serial port of the ground station laptop, the GUI looks for a predetermined byte sequence. When that byte sequence is found, the GUI truncates the remainder of the packet and sends the truncated version off for analysis. The secondary header serves as that predetermined byte sequence.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 64 Dept of Aeronautics and Astronautics

It may be possible to use the “Command” value in the packet header as a secondary header. Be forewarned that significant problems will arise if the system becomes unstable and the header bytes are lost (which has happened before).

If the system complexity increases, it will be possible to implement APID (APplication IDentification) functionality by adding to the secondary header. If multiple packets need to be transmitted per vehicle per time slot, APIDs can be used to confirm the identity of the packets being transmitted. Furthermore, APIDs can enable implementation of a dynamic communications system

B.2.1.3 Data The current communications system transmits and receives the following data structures:

• Vehicle 1 Primary Vehicle Array (PVA) • Vehicle 2 PVA • (optional) Vehicle 3 PVA • Ground Station Operational Commands

Each Primary Vehicle Array captures the following information:

• The local vehicle metrology data timestamp in seconds • The local vehicle metrology data timestamp remainder in milliseconds (the rest of the

timestamp after the number of seconds is truncated) • The distance to the first remote vehicle as measured from the local vehicle • The angle from the line of sight between the local vehicle and the first remote vehicle to

the local “east” direction • A timestamp to mark the creation of the local vehicle PVA in seconds • A timestamp to mark the creation of the local vehicle PVA with the remaining

milliseconds (the rest of the timestamp after the number of seconds is truncated) • The angular rate of the local vehicle, scaled and type-cast • The amperage of the first electromagnetic coil of the local vehicle, scaled and typecast • The amperage of the second electromagnetic coil of the local vehicle, scaled and typecast

The addition of a third vehicle into the system generates the following additions to each PVA:

• The distance to the second remote vehicle as measured from the local vehicle • The angle from the line of sight between the local vehicle and the second remote vehicle

to the local “east” direction

The Ground Station operational command data structure has not yet been determined.

B.2.1.4 Error-checking and correction routines The DR2000 employs a hardwired error-checking and correction routine known as ARQ, or Automatic Repeat Request. If a packet arrives in error, ARQ should request from the sending node that the offending packet be resent. The communications team has so far been unable to

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 65 Dept of Aeronautics and Astronautics

determine whether this function is actually working. To utilize ARQ, the packet definition includes two error-checking bytes in Frame Check Sequence (FCS) or Cyclic Redundancy Check (CRC) format (shown in Table B.2-A).

B.2.2 GUI (ESS) The GUI is simply a Graphic User Interface coded in Labview for the express purpose of real-time monitoring, control, and data logging of the system. After initialization, the GUI runs in an infinite loop until an error occurs or the user manually deactivates the virtual instrument.

B.2.2.1 Initialization The GUI performs all the necessary functions to initialize the laptop communications port to receive data from the DR2000. This process is transparent to the user as long as the default values are used for system constants.

B.2.2.2 String Capture The GUI waits a user-determined length of time for bytes to accumulate on the serial port. It then reads them in as a character string. This string is the ASCII interpretation of the byte data stream output by the DR2000.

B.2.2.3 String Parsing If the sample time is set properly and the DR2000 is successful in receiving good packets, each character string will contain at least one good packet. The GUI, using the “match pattern” virtual instrument, will examine the string until it finds the user-determined Header Tag. Once the header tag is located, the virtual instrument takes a substring of user-determined length from the original character string and passes it to the next function.

• If no header tag is found, an empty string is passed. • If multiple header tags exist (usually from multiple packets) only the first will be passed

on • If the number of bytes to be passed exceeds the data available, the rest will be zeros.

Ideally, one complete data packet will be passed as a character string to the next function.

B.2.2.4 Type Conversion The character string needs to be converted to an unsigned integer array, as this is how it was passed over the RF link from the vehicle. The high and low bytes are interspersed by a “for” loop and case function, creating a new array of unsigned integers.

B.2.2.5 Unit Conversion

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 66 Dept of Aeronautics and Astronautics

The variables passed over the communications system RF channel each have a different “actual” range prior to being scaled to unsigned integers. In order to see real-time data that makes sense, the scaled unsigned integers need to be converted back to their original data type and rescaled. This requires a conversion matrix with two columns and n rows, where n is the length of the integer array: the first is a binary variable that determines whether or not the variable needs to be converted to a signed variable; the second column is the scaling factor that converts the recentered integer into an actual float value in the appropriate units. As of May 2003, this functionality has not been implemented.

B.2.2.6 Data Logging The integer array is appended to the end of a spreadsheet file for later analysis.

B.2.3 Communication Procedures The communications software consists of two main procedures that operate within the Avionics operating system. The communications system’s responsibilities include:

• Taking in data from the other software modules within the local vehicle’s operating system

• Encoding the data for transmission • Transmitting the data to the other network nodes • Receiving the data from the other network nodes • Decoding the received data, and • Outputting the appropriate arrays to the other software modules running within the

operating system of the remote vehicles.

These responsibilities are divided into two procedures: transmit and receive.

B.2.3.1 Transmit The transmit function takes the local PVA array composed of 16-bit unsigned integers and packages it into an array of 8-bit high and low bytes for transmission. The high byte is simply the upper 8-bit chunk of the 16-bit unsigned integer shifted bitwise into byte format while the low byte is the lower 8-bit chunk of the same 16-bit unsigned integer.

For example, let’s suppose we have an unsigned integer of decimal value 20,000. In binary, this unsigned integer becomes:

0100111000100000

Thus, the low byte is:

00100000

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 67 Dept of Aeronautics and Astronautics

And the high byte is:

01001110

Note that the high byte is the original 16-bit value bit-wise “anded” (‘&’ in C) with 65280 decimal, or:

1111111100000000

And shifted right (‘>’ in C) by 8 bits.

The function then transmits this packaged array through the serial line connecting the TT8 with the DR2000 transceiver.

NOTE: The nature of the serial connection means that data can only be sent as bytes, which explains the necessity of packaging the data for transmission.

NOTE: The first bytes to be sent through the serial line to the DR2000 for each packet must be the five header bytes. If these are not sent through the serial line, the DR2000 will not send the packet.

IMPORTANT: There must be a delay between the transmission of each byte; otherwise there will be problems with the DR2000’s. The issue seems to be related to the DR2000 internal buffer. Apparently, the TT8 can send bytes to the DR2000 internal buffer faster than the communications board can read them. This mismatch in throughput will cause packet collisions. To avoid this problem, we have chosen a delay of 1 millisecond, which seems to be sufficient to keep the communications system working reliably with a high data throughput. The use of shorter delays has not yet been tested.

B.2.3.2 Receive The receive function (aka ‘Fetch’) accepts the data packets from the other network nodes by grabbing each byte as it appears in the serial line between the TT8 and the DR2000. As a byte comes into the TT8, it is assigned as an element value in a temporary storage array (PVA_Remote_Packaged, for example). When all of the data has been collected, the function converts this array back into a 16-bit unsigned integer array referred to as one of the PVA_Remote arrays or the GUI_Command array, depending on the source of the data. The other software modules can then retrieve these arrays as needed during the rest of the operating cycle (see Avionics for a description of the operating system).

B.2.4 Network Structure B.2.4.1 Node definitions The communications network node assignments for our system are as follows:

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 68 Dept of Aeronautics and Astronautics

• Node 1: GUI Ground Station • Node 2: Vehicle 0 • Node 3: Vehicle 1 • Node 4: Vehicle 2

B.2.4.2 Communications cycle The communications cycle is but one portion of the overall operating system cycle. Within the communications time slot, each node has a certain amount of time in which to transmit its data. The breakdown follows in Table B.2-B:

Table B.2-B: Communications Cycle Broken Down Into Time Slots

Time slot 1 Time slot 2 Time slot 3 Time slot 4 Node 2 transmit

All others receive Node 3 transmit

All others receive Node 4 transmit

All others receive Node 1 transmit

All others receive The Ground Station (node 1) communication is considered to be the lowest priority; hence it transmits last. Any commands sent by the ground station will be implemented in the next operating system cycle.

Each node broadcasts its data to every other node. Each vehicle requires information from all the other vehicles in order to make the appropriate control calculations. The only way to achieve this information flow is for each vehicle to broadcast their PVA. The command packets can then be directed to one or all of the vehicles. Since the current operating system allocates a fixed amount of time for each node to transmit, it makes sense to simply go ahead and broadcast all of the command packets, regardless of which communications node is the intended recipient.

B.2.4.3 Bandwidth usage The DR2000s transmit at 57,600 baud, which is 57.7 kbps equivalently. This represents our system data rate (since only one transceiver can transmit at any given time).

Given the fixed packet size chosen for the current version of the communications system, we know that we have:

• 5 header bytes (40 bits) • 32 data bytes (256 bits) • 2 CRC bytes (16 bits) • 78 start/stop bits (one start bit and one stop bit for each byte sent)

This gives a total of 390 effective bits for one packet.

Our current communications network transmits at most 4 packets per cycle (one command packet, and at most 3 vehicle PVA packets). This means we transmit 1,560 bits for a cycle with

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 69 Dept of Aeronautics and Astronautics

maximum bandwidth usage. Given our system baud rate, we can calculate the cycle length in milliseconds:

Cycle length = ondms

bitsonds

cyclebits

sec1000*sec

∗ (ms)

= (1560 bits/cycle) * (1/57600 seconds/bits) * (1000 ms / second) = 27.08 ms/cycle

Now we can calculate the number of communications cycles we can perform in a second:

Cycles per second = mscycle

ondms

083333.271*

sec1000

= 36.92 cycles/sec

B.2.5 DR2000 Communication

B.2.5.1 DR2000 Commands The DR2000 has several sets of very useful commands that should be kept handy at all times when dealing with the communications system. To use these commands, use the Microsoft Windows application HyperTerminal or another suitable serial port program such as Telix.

THESE COMMANDS ARE CASE-SENSITIVE.

The first set deals with commands for the local DR2000:

• To display the current DR2000 configuration

$$s

This command will cause the serial program to output configuration data that looks like:

• To change the “To Address” (in hex!)

$$TOADhh Valid digits: 0-f (00 – ff)

For reference, the node assignments for our system are as follows:

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 70 Dept of Aeronautics and Astronautics

o 0x31 Node 1: GUI Ground Station o 0x32 Node 2: Vehicle 0 o 0x33 Node 3: Vehicle 1 o 0x34 Node 4: Vehicle 2

REMEMBER: this value is stored in the flash memory.

• To change the “From Address” (in hex!)

$$FRADhh Valid digits: 0-9, a-f (00 – ff)

For reference, the node assignments for our system are as follows:

o 0x31 Node 1: GUI Ground Station o 0x32 Node 2: Vehicle 0 o 0x33 Node 3: Vehicle 1 o 0x34 Node 4: Vehicle 2

REMEMBER: this value is stored in the flash memory.

• To change the “Packet Size” (in hex!)

$$SIZEhh Valid digits: 0-9, a-f (01 – ff)

REMEMBER: this value is stored in the flash memory.

The Packet Size value that is stored in the flash is set once. It is not something that can be changed dynamically due to how the DR2000s are constructed.

The second set deals with commands for the remote DR2000s (these commands will affect the remote DR2000 with the same address as the “To Address” used by the local DR2000):

• To change the “To Address” (in hex!)

$&TOADhh Valid digits: 0-f (00 – ff)

For reference, the node assignments for our system are as follows:

o 0x31 Node 1: GUI Ground Station o 0x32 Node 2: Vehicle 0 o 0x33 Node 3: Vehicle 1 o 0x34 Node 4: Vehicle 2

REMEMBER: this value is stored in the flash memory.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 71 Dept of Aeronautics and Astronautics

To change the “From Address” (in hex!)

$&FRADhh Valid digits: 0-9, a-f (00 – ff)

For reference, the node assignments for our system are as follows:

o 0x31 Node 1: GUI Ground Station o 0x32 Node 2: Vehicle 0 o 0x33 Node 3: Vehicle 1 o 0x34 Node 4: Vehicle 2

REMEMBER: this value is stored in the flash memory.

• To change the “Packet Size” (in hex!)

$&SIZEhh Valid digits: 0-9, a-f (01 – ff)

REMEMBER: this value is stored in the flash memory.

B.2.5.2 TT8 Serial Settings The DR2000 connects to the TT8 via one the TT8 TPU Serial lines. The input channel (receive) is TPU channel 14 and the output channel (transmit) is TPU channel 13.

NOTE: The serial line baud rate MUST be set at 115.2 kbps. The modified DR2000’s are designed to match an RS232 baud rate of 115.2 kbps.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 72 Dept of Aeronautics and Astronautics

B.3 Metrology Code Overview (OM) The metrology code is written to handle various interrupts that are triggered by an internal clock timer and both the IR and ultrasonic receivers. The initialization of the code begins by defining global variables needed by the metrology system and initializing the interrupts. After these initial steps the metrology systems goes into an infinite loop and handles each interrupt.

B.3.1 Version documentation The version of the code is kept tracked by the variable CODE_VER. This variable is initialized at the beginning of the code and needs to be updated each time the code is updated.

B.3.2 Include Files The following table (Table B.3-A) provides a list of the included files. These files are needed for many of the TT8 functions to be used.

Table B.3-A: Include Files

File name Library Type Stdio.h Standard C math.h Standard C String.h Standard C Tt8.h TattleTale Model 8 Tt8lib.h TattleTale Model 8 Tt8pic.h TattleTale Mode 8 tpu332.h TattleTale Model 8 dio332.h TattleTale Model 8 Userio.h TattleTale Model 8 Stdlib.h TattleTale Model 8 time.h TattleTale Model 8

B.3.3 Input and Output Channels The following channels (please refer to Table B.3-B) are defined for integration with the TT8 and the metrology hardware. The table includes the variable name within the code, along with a description and the pin number for the TT8.

Table B.3-B: Metrology I/O Channels

Identifier Name/description TT8 Pin Type and # IR_RECV_CHAN IR receiver in TPU 0 US_RECV_CHAN1 US1 receiver in TPU 1 US_RECV_CHAN2 US2 receiver in TPU 2 US_RECV_CHAN3 US3 receiver in TPU 3 IR_XMT IR transmit TPU 4 US_XMT US transmit TPU 5 US_TIMER_CHAN Sequence timer trigger TPU 6 US_TIMER_RCV Sequence timer receive TPU 7 SendCHAN I/O to avionics TT8 TPU 8

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 73 Dept of Aeronautics and Astronautics

B.3.4 Global Variables The constants set here in Table B.3-C are used system wide. They identify what vehicle ID, which is required to determine when in the sequence to pulse IR and US signals. They also allow for time stamping IR and US signals for distance calculations and for time stamping the data sent to the avionics TT8.

Table B.3-C: Global Variables

Identifier Name/Description Used in function vehicle_ID Vehicle identifier main(), usSeq, usStateSeq Sequence identifier handleUSTimer(), ArmLength Length of metrology arm xylocation(), gIRArriveTime, gUSArriveTimeVec, usArriveTimes Timestamp of IR and ultrasonic arrival

times handleIR(), handleUSTimer()

GcounterRate Clock Rate main(), handleUSTimer() gIR_Usdelay Delay time between IR and US transmit handleUSTimer() PeriodDelay Delay between timing sequences handleUSTimer() centerDistance,centerAngle Distance and angle to other vehicle handleUSTimer(),

xylocation() Usdistance Distance from US transmitter of second

vehicle to US receiver handleUSTimer()

TimeStampIR IR receive timestamp handleIR(),

B.3.5 Function Prototypes Each task of the code is divided into a function. Each function is responsible for a specific task and is called upon when needed. A list of the function prototypes is included in Table B.3-D.

Table B.3-D: Function Prototypes

Function name Description void SetupIRRcv(void) Setup IR receive interrupt void SetupUSRcv(int CHAN) Setup ultrasonic receive interrupt void SetupIRXmt(void) Transmit IR void SetupUSXmt(void) Transmit ultrasonic void handleIR(void) Handle the IR signal when interrupt is triggered void handleUSTimer(void) Handle the US Timer when the interrupt is

triggered void SetupUSTimer(void) Setup the US Timer void SetupUSTimerRcv(void) Setup the US Timer receive interrupt double xylocation(double distanceA, double distanceB, double

distancC, int satNum) Calculate the distance from center of vehicle to second vehicle

B.3.6 Metrology Design Overview The metrology system currently uses data obtained from IR and ultrasonic sensors to calculate the relative distance and angle of each vehicle. Each vehicle is equipped with one omni-directional ultrasonic transmitter, three omni-directional ultrasonic receiver, four omni-directional IR transmitter arrays, and three IR receiver arrays. There are multiple IR transmitters in case one transmitter has a limited field of view due to other devices needed on the metrology

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 74 Dept of Aeronautics and Astronautics

system. Also, the power of the IR signal is limited to each IR transmitter, by adding an array of transmitter we are able to guarantee the signal can reach the receiver of the other vehicles. There are multiple IR receivers because the receivers do not have a 360° field of view. The three receiver arrays allow us to cover the full field of view required for the system to work properly. The system then uses the position of the ultrasonic receivers and the time difference between the IR and ultrasonic receivers to calculate the relative distance and angle. The current design of the system uses a Tattletale 8 processor (TT8), which is capable of handing ultrasonic and infrared transmitters and receivers. All code is written in C, which is easily uploaded on the TT8 via a serial connection from a PC. The timing sequence shown in Figure B.3-A was created to map out the sequence of events for the metrology system.

Figure B.3-A: Metrology System Timing

The first event begins with the master vehicle. Each vehicle is assigned master, slave 1, or slave 2 prior to the test. This label is available to each vehicle and can be set prior to each test over the communications port or prior to software load. The master vehicle emits an IR pulse. Each vehicle then receives the pulse (assumed to be instantaneous since the speed of light is much greater than the speed of sound) and causes an interrupt to be triggered on the TT8. The IR triggered interrupt begins a timer, usTimer, which sets the TPU pin high or low at given times. When the TPU pin is set high, a second interrupt is triggered causing the TT8 to do a sequence of events based on timing and vehicle ID. Two counters are used to track the sequence

MasterIR Trans

US Trans

Slave 1

IR Rcv

US Trans

Slave 2

IR Rcv

US Trans

Time(ms)

US Rcv

US Rcv

IR RcvUS Rcv

0 10 30 50 705 25 45 65

US Timer

usSequsStateSeq

0 1 0 1 0 1 0 1

0 0 1 1 2 2 3 3

100

0

4

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 75 Dept of Aeronautics and Astronautics

of events. One counter, usSeq, oscillates between 0 and 1, switching back and forth each time the timer interrupt is triggered. A second counter, usStateSeq, increments by 1 each time usSeq resets to 0. The following flow chart (Figure B.3-B) is followed once each vehicle receives the IR signal. The first command after the IR is received is to setup the timer, usTimer, to initiate the next interrupt in 5ms. It also initializes the counters, usSeq and usStateSeq, to zero. Following that, it enters a loop, allowing two separate events to occur depending on the value of usSeq.

Figure B.3-B: Beginning Coding

Sequence

When usSeq is zero, the following events occur (as seen in Figure B.3-C). The first check is to determine if the

vehicle is in the beginning of the sequence (usStateSeq < 3) or the end. If usStateSeq is less than three, the vehicle then reads in the US receiver data. This data is the time stamp of the US signal arriving to the receiver, later used to determine the distance of the US signal. Following this, the code then checks to see if the state and vehicle ID match. If this is the case, the vehicle prepares to transmit an US pulse, otherwise it prepares to receive a US signal. Next, it resets the usTimer to initiates the next interrupt 15ms later. Finally, it increments usSeq by one and restarts the loop. If the state is greater than three, a separate group of events occur. In this case usStateSeq and usSeq are reinitialized to zero. Next, a check occurs to see if the vehicle is the master. If this is the case, an IR pulse is emitted. The code then restarts the loop (including restarting the entire

timing sequence). Figure B.3-C: Loop for usSeq = 0

Start IR Rcv Setup US Timer

5 msusSeq = 0

usStateSeq = 0

1

0

usSeq= 1

2

Yes

No

usStateSeq =vehicle ID0 usStateSeq° 0 Setup

US Rcv

Setup US Xmt

Read US Rcv

Setup US Timer

15 ms

usSeq = 1

2

Yes

YesNo

No

usSeq = 0 usStateSeq = 0 IR Xmt

usStateSeq < 3

No

Yes

VehicleID = 0Yes

No

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 76 Dept of Aeronautics and Astronautics

When usSeq is set to one, the following events occur (as seen in Figure B.3-D). The highest priority task in the loop is the transmission of the US signal. This event is the first that takes place, with only a simple check to see if the vehicle is required to emit a US signal at that instant in the sequence. After that check, a second check is made to identify the location within the timing sequence. If the sequence corresponds to a usStateSeq of less than three, the US timer is reset to 5 ms, usSeq is reinitialized to zero, and the code is looped to the beginning. If this not true, corresponding to the end of the US transmissions, the distance is calculated and sent to the main processor. In addition, the IR receiver is setup to receive another signal and the US timer is reset to 30 ms (to ensure the next IR signal is sent at 100ms). Finally, usSeq is reinitialized, and the loop is restarted.

Figure B.3-D: Loop for usSeq = 1

B.3.7 Distance Determination Code

As a result of the transmitter and receiver code, each sensor will have a distance to each (3 sensors x 2 vehicles = 6 distances). These distances will then help the vehicle to determine a distance and angle from center of the vehicle sending the signal to the center of itself. The following algorithm is then used to determine the distance and angle. This algorithm is depicted graphically in Figure B.3-E. Since only two sensors are needed to determine the two unknowns (distance, r, and angle, θ) the two sensors that read the closest distance are used. By eliminating the third sensor we are able to get an initial idea of where the signal came (reducing the signal origin to a certain range). A temporary frame of reference is set to the two sensors, with the origin at one sensor and the second sensor (x0,0) away. Since the distance is know to each sensor, you can determine the coordinates of the originating signal relative to the temporary frame. Once that coordinate is determined, the frame is then rotated and translated so that the frame of reference is centered at

usStateSeq =vehicle ID1 US Xmt usStateSeq <

3

Setup US Timer

5 ms

Setup US Timer

30 ms

Dist CalcConstruct PVA usSeq = 0

2

No

NoYes

Yes

usStateSeq =3

SendData

SetupIRRcv

Yes

No

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 77 Dept of Aeronautics and Astronautics

the center of the vehicle. The coordinates are the converted from Cartesian to polar so that an r and θ are known.

A

B C

d1d2

x2

y

xA C

x 2 + y 2 = d12

(x − x2)2 + y 2 = d22

x =x2

2 + d12 − d2

2

2x2

y = d12 − x 2

A

B C

Figure B.3-E: Distance Determination Sequence

B.3.8 Metrology Software: Modules Main() The main function initializes the system to run. After printing out

information (version number and the date and time compiled), the system runs into an infinite loop. To exit the loop, the avionics TT8 needs to send a start byte, which is a single byte containing the vehicle ID.

Next, the code then enables the interrupts (IR receive and the clock timer). Following this, it sends the first IR pulse (if the vehicle is the master vehicle). Then it enters an infinite loop and just handles all interrupts.

SetupIRXmt() This function transmit the IR pulse. It uses the standard embedded

function QOM. QOM is defined in the TT8 users guide. SetupUSXmt() This function prepares to transmit the ultrasonic pulse. The line of code

that is commented out, enables the channel. This is needed to send the signal to pulse. The function uses the standard embedded function QOM. QOM is defined in the TT8 users guide.

SetupIRRcv() This function prepares the IR receiver. The function uses the standard

embedded function ITC. ITC is defined in the TT8 users guide. This allows the signal to trigger an interrupt (handleIR).

Start Determine 2 closes sensors

Calculate coordinatesin sensor frame

Rotate and translateto body frame

Calculate distance and angle End

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 78 Dept of Aeronautics and Astronautics

SetupUSRcv() This function prepares the ultrasonic receiver. The function uses the

standard embedded function ITC. ITC is defined in the TT8 users guide. handleIR() This function is used when the IR pulsed is received. The IR pulse

triggers an interrupt that calls handleIR(). The function timestamps the IR pulse by calling a standard TT8 function StopWatchTime() (this allows us to timestamp the data for use later on in data analysis). It then initiates the timing sequence (US timer) that will initiate the events described in the software design. Finally it clears the IR interrupt, so that an unintended IR signal won’t trigger the interrupt again (this is re-enabled in a later part of the code when the next pulse is expected).

SetupUSTimer() This function initiates an timer that will send a pulse at the end of the

timer. This function uses an embedded function QOM. QOM is defined in the TT8 users guide.

SetupUSTimerRcv() This function prepares the IR receiver. The function uses the standard

embedded function ITC. ITC is defined in the TT8 users guide. This allows the signal to trigger an interrupt (handleUSTimer).

handleUSTimer() This function handles most of the sequencing and calculating in the

metrology system. The function uses the variables of usSeq and usStateSeq to keep track where the code is in the sequence of events. The section on software design describes the order of events.

xylocation() This function calculates the distance and angle to the center of vehicle

using the data from the three ultrasonic receivers. The algorithm is described in the software design section.

B.3.9 Calibration Data The data shown in Figure B.3-F was obtained to calibrate the hardware and correct for any error in the system. The first test was a distance calibration. In this test the angle was kept constant and the distance was varied. The graph shows the actual distance from the transmitter and receiver and the data received from the metrology TT8. The data was averaged and a standard error was calculated. Error bars are included to show the deviation between all the points that were averaged.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 79 Dept of Aeronautics and Astronautics

Figure B.3-F: Distance Calibration

The second test was an angle calibration. In this test, the distance is kept constant and the angle varied (at 30 degree increments). Figure B.3-G shows the actual angle from the transmitter and receiver and the data received from the metrology TT8. Again, the data was averaged and a standard error was calculated. Error bars are included to show the deviation between all the points that were averaged.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 80 Dept of Aeronautics and Astronautics

Figure B.3-G: Angle Calibration

The error between the actual values and the readings can be attributed to the value for the length of the arm of the metrology system. This value is included in the code and used in the angle calculation (it is also used for distance). A rough test to see how the length was critical to the sensitivity to the calculation was done. Although no data was collected, it was noted that moving the distance of one US receiver up to an inch varied the angle by up to 12 degrees. More test need to be done to get data on its sensitivity, but it should be noted that the distance from the center of the system to the ultrasonic sensor (defined as ArmLength in the code) needs to be accurate.

C Avionics Hardware Design (SS)

C.1 Avionics Board Interfaces It is essential to identify the interfaces in order to ensure a complete and functioning Avionics/electronics subsystem. The primary role of the Avionics subsystem is to integrate all hardware and software of the system; therefore, the Avionics hardware must interface with all other subsystems. Central to the Avionics subsystem is the Tattletale Model 8 computer. The Avionics team has chosen to utilize the Tattletale Model 8 computer (TT8), with Motorola CPU (Central Processing Unit) and TPU (Time Processing Unit), because it both suits project processing needs and is readily available in the Space System Laboratory. This computer interfaces directly with four other pieces of hardware: The Metrology computer, the voltage regulator, the Communications board, and a series of mosfets used for power amplification purposes. This hardware conceptual layout is depicted in Figure C.1-A.

RWA

EMPowerAmp

PWR (D)

Computer(CPU/TPU)

Comm./Ops

V Reg.

RS 232

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 81 Dept of Aeronautics and Astronautics

Figure C.1-A: Avionics Hardware Interfaces

Each hardware interface is necessary and vital to each EMFFORCE vehicle. The necessity for these interfaces is explained as follows:

• The Metrology computer is another Tattletale Model 8 computer. The Avionics subsystem must allow for the sending of Primary Vehicle Array (PVA) updates through a serial channel from the Metrology TT8 to the main Avionics TT8 computer.

• The Power team is responsible for the voltage regulator. However, the Avionics team is responsible for the interfacing between the voltage regulator and the rest of the system. The voltage regulator allows for a steady 5V power to come from the AA batteries to the Tattletale computers and the Avionics board. The Power and Operations teams shall address any other power concerns and notify the Avionics team in a timely manner such that any new concerns can be addressed properly in the system design.

• The communications/operations hardware is the hardware that allows for the sending and receipt of all data being transmitted and received from the immediate vehicle system to the Avionics TT8 and vice versa. The Communications board interfaces with the Avionics TT8 through a serial RS232 cable connection.

• A circuit design of mosfets, like the voltage regulator, is the responsibility of the Power team. However, the intergration of the mosfets into the vehicle system is the responsibility of the Avionics team. These mosfets shall ensure that the power derived from the D-cell main batteries supply the necessary level of current needed to drive the Reaction Wheel Assembly and the Electromagnets.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 82 Dept of Aeronautics and Astronautics

C.2 Avionics Board Wiring and Schematic The Metrology and Avionics Tattletale computers shall be attached to the Avionics board via one TSW-116-07-SS connector and one TSW-120-07-SS connector per Tattletale computer. The two Tattletales communicate via one Tx line and one Rx line. Four RS-232 jacks, (corresponding to the Serial1 and Serial2 lines for each computer) shall be placed on the board, in a manner such that code loading can easily occur. The Digital Ground (DGND), -MCLR, and –IRQ3 lines shall have male connectors such that a female connector can be used to load programs (DGND must be paired with either –MCLR and –IRQ3 to load either FLASH or ROM). The Communications board shall be connected to the main Avionics board via another RS-232 cable. This connection requires from Avionics a transmit, a receive, and a digital ground line. Three Ultrasonic (US) signals shall all be inputs to the Metrology TT8 while the three Infrared (IR) signals shall converge through an OR gate before metrology computer processing. This single IR signal shall also be sent to the Avionics TT8 for time synchronization purposes.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 83 Dept of Aeronautics and Astronautics

Figure C.2-A: Avionics Board Wiring Schematic

C.3 TT8/Avionics Board Pin Allocations The Avionics team established the following input/output pin allocations so that every subsystem can transmit and receive data when necessary. The following pins have been allocated for the following functions on the Metrology and Avionics TT8 computers. The “TP” prefix refers to a TPU channel, and the “AD” pin and channel prefix refers to a pin connected to the TT8’s internal A/D converter. A pin on the Avionics board or on the Metrology board is signified, respectively, by an “A” or an “M” appended to either the “TP” or “AD” prefix. Table C.3-A lists the Avionics computer TT8 pins, their functions, and whether it is for an input or an output signal from the Avionics computer while lists the same for the Metrology computer. Loading of software code shall occur via serial port. TT8-to-TT8 and TT8-to-Communications Board communication shall occur via serial lines made by the Avionics team. Two TPU pins and the ground pin are necessary for each of these serial lines.

Table C.3-A: Avionics IO Pin Allocations

Channel/Pin Purpose Input or Output?

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 84 Dept of Aeronautics and Astronautics

TPA0 Actuation 1, Electromagnet Output TPA1 Actuation 2, Electromagnet Output TPA2 Reaction Wheel Output TPA3 TT8-to-TT8 Communication, Tx Output TPA4 TT8-to-TT8 Communication, Rx Input TPA5 IR (input from met.) TPA6 (not needed yet) Actuator Stop Output TPA7 Small Control Loop Input? TPA8 PWM Output Serial1 Used for loading of code Input Serial2 TT8-to-Comm. Board Input and Output AA1 Ground line Input AA4 -MCLR Output AA5 -IRQ3 Output ADA1 EM Amperage Input ADA2 EM Amperage Input

Table C.3-B: Metrology I/O Pin Allocations

Channel/Pin Purpose Input or Output? TPM0 Infrared Input TPM1 Ultrasonic 1 Input TPM2 Ultrasonic 2 Input TPM3 Ultrasonic 3 Input TPM4 Infrared Output TPM5 Ultrasonic Output SerialM1 Used for loading of code Input SerialM2 Used for loading of code Input TPM6 TT8-to-TT8 Communication, Tx Output TPM7 TT8-to-TT8 Communication, Rx Input AM1 Ground line Input AM4 -MCLR Output

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 85 Dept of Aeronautics and Astronautics

AM5 -IRQ3 Output

C.4 Avionics Board Capture Drawing The following schematic (please refer to Figure C.4-A) was developed utilizing OrCAD Capture and shows the individual parts and connections to be included for the avionics board design.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 86 Dept of Aeronautics and Astronautics

Figure C.4-A: Avionics Board OrCAD Capture

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 87 Dept of Aeronautics and Astronautics

C.5 Avionics Hardware Testing Integration has been completed in a series of steps. The following different tests and projects were performed to ensure proper avionics hardware design, integration, and compatibility with the vehicle as a whole. The dates that these stages occurred are also noted.

• Dec2002 – May2003: A prototype board and design concept for the actual Avionics board is designed and used. At this point, tests shall be conducted to ensure proper coding and board design theory as well as to verify correct design of the various subsystems. The prototype “ board” includes 2 IO-8 prototyping boards manufactured by Onset Computers, 1 prototyping breadboard with metrology OR gate chip for IR signal timing transmission, RS-232 cables used for both TT8-to-TT8 communication and TT8-to-Communication board communication, and all wiring of signals from each I/O channel. This prototype system is currently still being used on Vehicle 1, and has allowed successful completion of tests 1A and 1B.

• Apr2003: The manufactured boards were first compared to the OrCAD Layout and Capture drawings to ensure that they were manufactured to our specifications, and then tested with a scope to ensure proper connections. These assurance tests were completed successfully.

• 24Apr2003: Two avionics electronics boards are populated according to to-date specifications. Metrology software and hardware were integrated into the system without fault.

• 29Apr2003: It was determined that the current design of the avionics software needed 5 more digital channels for functionality. The manufactured board design only included 5 excess A/D channels and no extra digital channels. Therefore, the two boards were hardwired to meet the needs of the software.

• 01May2003: Software integration with the Avionics electronics board commenced. The Metrology TT8 and the Avionics TT8 were not communicating; bypassing the OR-gate solved this issue.

• 08May2003: Hardware/electronics integration on Vehicle 2 begins.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 88 Dept of Aeronautics and Astronautics

C.6 Avionics Circuit Board Part Information Each Avionics circuit board includes the following parts:

• Main avionics circuit board: The board is a prototype board manufactured by Advanced Circuits, Inc. (see www.4PCB.com for more information).

• Motorola TT8C Computers: Each board has 2 of these. • CD4075: This is the Or-gate chip necessary for IR processing. It is a “dip” chip. For

part specification, see C-7. • Screw terminals: four 5-terminal screw blocks, 1 12-terminal screw block, 1 6-terminal

screw block are needed per board. For the part specification, see C-8. • Headers: The TT8 is connected to the board with one 16-pin and one 20-pin header per

computer.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 89 Dept of Aeronautics and Astronautics

C.7 Part Specification for Screw Terminals

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 90 Dept of Aeronautics and Astronautics

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 91 Dept of Aeronautics and Astronautics

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 92 Dept of Aeronautics and Astronautics

D Carriage Design (ALS) The air carriage system is composed of a CO2 gas supply system, pucks, and carriage.

D.1 Gas Supply A tank containing liquid CO2 supplies the gas for the carriage. The tank is mounted in a vertical position with the outlet at the top. This ensures a desirable configuration for steady gas flow. During operation, the tank must sit in a warm water bath to keep the tank temperature from dropping too quickly. If the temperature drops too low and too quickly, dry ice chunks will form inside the tank, and not only will some of the gas be unavailable for use, but the flow path could be restricted and the supply pressure could drop. A bath of hot tap water is sufficient to keep this from happening. The high-pressure outlet of the tank (860 psi) connects, via a bottomline hose, to a reducing pressure regulator. The chosen Tescom regulators are capable of reducing up to 3500 psi to a range of 0-100 psi. The EMFFORCE system operates between 12-35 psi. A gauge allows the operator to manually set the desired operating pressure depending on the floor surface. The low-pressure discharge from the regulator is split via a manifold into three flexible tubes routed to the pucks.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 93 Dept of Aeronautics and Astronautics

D.2 Pucks and Carriage The pucks selected for use on the carriage are 100 mm in diameter and have a single outlet aperture. They are equally spaced (120° apart) around the base ring underneath the vehicle. This configuration allows the pucks to maintain co-planarity with relative ease, while the ring adapts the three-armed tripod of the puck configuration with the four-“armed” cross configuration at the base of the magnet containment rings. Figure D.2-A shows the base ring with the pucks attached.

Figure D.2-A: Base ring with pucks attached

Also, the pucks are not rigidly attached to the rest of the carriage; rather, they are attached by screws with finger springs placed between the puck and the ring to allow them some play. This also ensures their ability to remain coplanar in the event of slight imbalance and force shifts. The main carriage base, to which the pucks are attached, is a rigid structure, rigidly attached to the rings of the magnet containment rings. Figure D.2-B shows a closer view of the puck-base interface.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 94 Dept of Aeronautics and Astronautics

. Figure D.2-B: Close-up view of puck attached to base ring

At the time of this publication, the air carriage is able to supply approximately seven and a half minutes of float time. It may be desirable to increase this time for longer tests. To do this with the current setup, a larger CO2 tank is required. Twenty-ounce capacity tanks are available through paintball suppliers. Alternatively, some research on lubrication theory and gas bearing behavior has been conducted by Jeannette Garza (Course 2, 2003). This research may be consulted to refine the arrangement of the air carriage. Unfortunately, the use of the gaseous nitrogen from the cryogenic system boil-off was ruled infeasible by the structures team under the constraints of schedule and manpower. In future iterations of the project, the structures team would like to see this option reopened and explored. Table D.2-A shows a list of specific parts and quantities required to assemble one carriage. The components in the table are referenced by letter to their location in Figures D.2-B, D.2-C and D.2-D.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 95 Dept of Aeronautics and Astronautics

Table D.2-A: Air Carriage Parts List

Qty. Part Description Vendor Vendor P/N A 1 16 oz. Capacity rechargeable CO2 tank B 1 Standard paintball bottomline kit www.paintballarmory.com 42041 C 1 Reducing coupling (1/8"NPT x 1/4"NPT

brass) McMaster-Carr 9171K72

D 1 Nipple (1/4"NPT brass) McMaster-Carr 9171K214 E 1 Tescom regulator Northeast Engineering 04-1C3ANN F 1 Pressure gauge (0-100 psi) McMaster-Carr 4089K24 G 1 Instant tube fitting adapter (1/4"NPT x

1/8”OD tube) McMaster-Carr 5779K243

H 6 Instant tube fitting adapter (1/8"NPT x 1/8”OD tube)

McMaster-Carr 5779K102

J 1 6-port manifold (2-1/4”NPT, 4-1/8”NPT) McMaster-Carr 5469K151 K 1 Hex plug (1/4" NPT brass) McMaster-Carr 9171K47 L 1 Hex plug (1/8" NPT brass) McMaster-Carr 9171K46 M 3 100mm dia. Aluminum pucks Self-manufactured N 6 ft General purpose PVC tubing, 1/8"OD McMaster-Carr 5233K51 O 3 Finger springs McMaster-Carr 9717K55 P 6 6-32 x 1/2" screws McMaster-Carr 90604A148

Table D.2-B: Tank, bottomline, and regulator assembly

E

D

C

B

A

F

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 96 Dept of Aeronautics and Astronautics

Table D.2-C: Manifold assembly

Table D.2-D: Puck assembly

O

P

H

M

K

H

J

L

N

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 97 Dept of Aeronautics and Astronautics

E Reaction Wheel Design (LW, WF)

E.1 Role of RWA (LW) The spin-up process requires equating the centripetal force on a vehicle with the electromagnetic force generated by the magnets. This process is depicted in Figure E.1-A and in Figure E.1-B. Figure E.1-A shows the initial configuration of the dipoles. Although the finalized design of the system uses two large, coreless electromagnets, the electromagnets are represented here as effective dipoles. The dipoles begin perpendicular to each other.

Figure E.1-A: Initial Dipole Configuration

Figure E.1-B depicts the two dipoles as they begin to spin up. As soon as a current is applied to the electromagnets, forces and moments are induced in the dipoles. The moments are due to the perpendicular geometry of the system at this point. These moments must be counteracted by applied torque from the RWA. The dipoles initially move in the directions of their respective net forces. As they begin to move, the applied torque from the RWA is decreased to induce centripetal motion of the system. As centripetal force increases, the applied torque continuously decreases, allowing the rotating dipoles to slowly align along the same axis. At the point where the dipoles are perfectly aligned and the centripetal force is equal to the total magnetic force, no more applied torque is necessary. At this point, the system is in steady-state rotation Figure E.1-B shows the process of spin-up.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 98 Dept of Aeronautics and Astronautics

Figure E.1-B: Spin-up Configuration

The RWA consists of a flywheel and a motor. The motor powers the flywheel and must provide the necessary torque to balance the moments that are produced by the electromagnets. The spinning wheel stores the system’s angular momentum, balancing the system and guiding the system through spin-up to steady-state rotation. The RWA functions on the principle of the conservation of angular momentum. Angular momentum is conserved because the spin-up maneuver is performed entirely using torques and forces that are internal to the system. Therefore, the sum of the angular momentum that accumulates in the wheels on the (in this case) two vehicles is equal and opposite to the angular momentum associated with the spinning of the system about its own center of mass.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 99 Dept of Aeronautics and Astronautics

E.2 Requirements • Wheel

o As a minimum, the flywheel must store the angular momentum necessary to operate a two-vehicle system in a steady state maneuver. The vehicles will perform the maneuver at a separation distance (between vehicle centers) of two meters and a rotation rate of one rotation per minute.

o The flywheel may not be made from an electrically conducting material. The electromagnetic field in which the wheel must operate would induce eddy currents in any wheel made from conducting material. Eddy currents would act as a retarding force against the motion of the wheel and this would hurt the performance of the reaction wheel assembly.

o The maximum wheel diameter is limited by the total vehicle size to less than half of a meter.

o Due to the material properties of the flywheel the wheel must be capable of storing the necessary angular momentum while operating at a speed below seven thousand rotations per minute.

• Motor

o The motor in the RWA must provide sufficient torque to accelerate the flywheel in either direction in order to counter moments induced by the electromagnets.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 100 Dept of Aeronautics and Astronautics

E.3 Wheel Design (WF)

E.3.1 Material Selection The design of the reaction wheel assembly was complicated with the decision from the Electro-magnet team to use hoops of super conducting wire to generate the necessary magnet forces to operate the vehicles. The reaction wheel assembly will be placed inside these hoops and therefore will be operating inside of a magnetic field. Due to problems with eddy currents, which act as strong resisting force to spinning metal wheels inside of a magnetic field, the flywheel cannot be made from any metallic materials. This forced the search for non-metallic materials with a sufficient density and structural rigidity to provide for the angular momentum storage of the vehicles. High-density urethanes appear to be the best solution. These materials provide the density and structural properties necessary to perform as needed and can also be molded into any shape for a relatively low cost. The reaction wheel assembly team has decided to use urethane wheels to be manufactured by Advanced Urethane Solutions because of their ability to meet all of our specifications at a low cost and with a reasonable delivery time.

E.3.2 Basic Geometry The flywheel consists of a thick outer ring and thin inner disk. Moment of inertia is dependent on the total mass of material used and the distance of that material from the axis of rotation. The most efficient flywheel design places a majority of the flywheel mass far from the axis of Rotation - the center of the flywheel. Figure E.3-A depicts the basic geometry used as the starting point in the flywheel design.

Figure E.3-A: Basic Geometry of Initial Flywheel Design

E.3.3 Governing Model The flywheel on each vehicle must be capable of storing one half of the total angular momentum of the entire system. This is necessary to allow the system to spin up from a static equilibrium into a steady-state rotation, which is a maneuver that will be conducted for this project. The total angular momentum that must be stored in the reaction wheels must be equal to the angular momentum generated during the spin up of the vehicles.

2tot

rwHH =

Equation E.3-1

rrw

rdiskhring hdisk

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 101 Dept of Aeronautics and Astronautics

It is necessary to determine both the angular momentum that will be created by the system and the total angular momentum that can be stored by the reaction wheel. Angular momentum is the product of the mass moment of inertia and the angular rotation rate.

Ω= IH Equation E.3-2

The mass moment of inertia of the entire system is found by summing the contributions of each of the individual vehicles. The total mass moment of inertia of the system is found using the parallel axis theorem.

))

2((2 2smII vehvehtot +=

Equation E.3-3

Where Iveh is the mass moment of inertia of an individual vehicle, mveh is the mass of a vehicle, and s is the separation distance between two vehicles. It is not possible at this time to get an exact value for the mass moment of inertia for each vehicle (Iveh). However, it is possible to make estimates from the contributions of each of the vehicle components and sum those contributions. The mass moment of inertia for each of the major vehicle components can be found in Table E.3-A below.

Table E.3-A: Mass Moment of Inertia Values

Component Mass Moment of Inertia

Outer electromagnet ring and container .34 kg m^2

Inner electromagnet ring and container .24 kg m^2

Batteries .032 kg m^2

Metrology .1 kg m^2

Air Pucks .1 kg m^2

Other .05 kg m^2

Using the results from Table E.3-A and adding a margin of error of 4.5%, the mass moment of inertia for each vehicle, about its center of mass, is approximately 0.9 kg m2. The current test plan calls for the two vehicles to separated by a distance of 2 m and rotate at one RPM with a vehicle mass of 18 kg. Using this information in Equation E.3-2 gives the total angular momentum of the vehicle as 3.96 kg m2/s. The maximum velocity of the wheel is limited by the structural integrity of the material when spun at high angular velocities. For the current wheel design and material properties, the maximum speed of the wheel before structural failure is 15,000 RPM (see section 3.4 below) and before structural deformation is 7,000 RPM. In order to ensure the safety of the wheel and those operating the vehicle, we have set the design operating velocity for the flywheel to be 2000

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 102 Dept of Aeronautics and Astronautics

RPM. For an operating velocity of 2000 RPM and the total angular momentum of 3.96 kg m2/s calculated above, Equations E.3-1 and E.3-2 yield a necessary mass moment of inertia for the flywheel of 0.01 kg m2. The mass moment of inertia of the flywheel is dependent on the specific geometry of the wheel and can be found by treating the disk and ring separately and superimposing the results. From Figure E.1-B, the mass moment inertia of the disk is given by:

4

2 diskdiskdisk rhI πρ= Equation E.3-4

The mass moment of inertia of the ring is given by:

)(

244

diskrwringring rrhI −=πρ

Equation E.3-5

Summing Equations E.3-4 and E.3-5 yields the total mass moment of inertia for the flywheel.

])([

2444

diskdiskdiskrwringrw rhrrhI +−=πρ

Equation E.3-6

In these equations, the geometric variables are as defined in Figure E.3-B and the density, ρ, is 1140 kg/m3. The final geometry of the flywheel was determined using Equation E.3-6 and taking into consideration the manufacturability of the design. The final wheel design is specified in Figure E.3-B. This final geometry meets the design requirements and provides a wheel with a mass of 1.1 kg.

Figure E.3-B: Final Wheel Design

E.3.4 Structural Integrity Disks spinning at high angular velocities can experience incredibly large stresses. In order to ensure the safety of our system, the flywheel must be capable of withstanding the stresses that it will experience during operation. The stresses for the flywheel are greatest in the lip of the ring. The maximum stress for a spinning ring is given by

0.124m

0.1m0.03m 0.015m

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 103 Dept of Aeronautics and Astronautics

)

31(

43 222

max IO RRvννρωσ

+−

++

= Equation E.3-7

where ω is the spin rate of the system, RO is 0.124m and RI is 0.1m and ν is the Poisson ratio of the material. For the urethane wheels we are using, the ultimate stress is 36 MPa and the yield stress is 9 MPa. Thus, the angular velocity at which the wheel will fail is 15,000 RPM and the rate at which the material will begin to yield is 7,000 RPM. In order to prevent failure, the system is designed to operate at 2,000 RPM and voltage limits will be placed on the power supplying the motor to prevent it from spinning faster than 5,000 RPM.

E.3.5 Vendor Information The final wheel design, as depicted in Figure E.3-B, was fabricated by Advanced Urethane Solutions, Inc. The wheel was manufactured using Advanced Urethane Solutions 90A urethane. Advanced Urethane Solutions is located at 3912 Tyron Courthouse Road; Cherryville, NC and can be contacted by phone at (888) 287-3842. The contact for this project was Application Specialist Joe Bell.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 104 Dept of Aeronautics and Astronautics

E.4 Motor Selection (LW)

E.4.1 Determination of Required Torque The torque required by the motor is that necessary to provide an acceleration of the flywheel in either direction that will counter the moments induced by the electromagnets. Due to the principle of the conservation of angular momentum, the torque required by the motor is equal to the torque resulting from the spin-up of two electromagnet dipoles. The greatest torque is the initial torque, the torque required to initiate the spin-up process. The relationship for the magnetic moments of the (in this case) two dipoles is given in Equation E.4-1:

0

4.25

3432

µωωπµµ +

=mr

BA Equation E.4-1

The relationship for α, the angle at which the magnet is rotated from its initial position, is given in Equation E.4-2:

⎟⎟⎟

⎜⎜⎜

+

−= −

4.2

21

4cos

ωω

ωα

Equation E.4-2

The relationship for the torque induced by the (in this case) two dipoles is given in Equation E.4-3:

( )α

µµµπ

τ sin224

13

0

rBA−

= Equation E.4-3

Combining Equations E.4-1, E.4-2, and E.4-3 yields a simplified expression for the torque induced by the dipoles:

2

.

34 mrωτ −

= Equation E.4-4

The boundary conditions applied to the system are given in Equation E.4-5. These conditions are derived from the requirements of the spin-up process. The dipoles begin spin-up from rest; therefore there should be no angular momentum in the initial state. The requirement for spin-up stipulates that the vehicle will be spinning at a rate of one revolution per minute at the conclusion of spin-up. This requirement drives the end boundary condition.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 105 Dept of Aeronautics and Astronautics

( )

( )6022

00ππω

ω

=

=

Equation E.4-5

The equations given in Equation E.4-6 show the general relationships for ω and Θ (the angle

between the dipoles in the x-y plane). This analysis assumes that acceleration is constant: .

ω is constant.

2

.

.

21 tdt

t

ωωθ

ωω

==

=

∫ Equation E.4-6

From the given expressions above, including the boundary conditions, a value for .

ω may be obtained:

3600

. πω = Equation E.4-7

Applying a mass of 18 kg and a separation distance of 2 m to the system, the torque induced by the dipoles may be calculated. This torque is the torque required by the motor in order for the dipoles to spin up according to protocol.

Nm 021.0=τ Equation E.4-8

A margin of 375% was applied to this result for the motor selection process. The torque requirement for the motor was set at 0.1 Nm to insure that spin-up will occur properly, i.e. the system will function as specified.

E.4.2 Motor Comparisons Two main classes of motors were examined: industrial brushless motors and model motors (for airplanes, boats or cars). The industrial brushless motors easily provide the torque required by the system. However, they are much more massive than the model motors and also more expensive by a factor of four. Most of the model motors are not capable of providing the necessary torque (and were therefore eliminated from the search). However, a certain class of model airplane motors is capable of providing sufficient torque for spin-up. Both the brushless and model motors run from variable voltage supplies, but the brushless motors require a much higher range of voltage, ranging up to a high of 50 required volts. Such high required voltages place a large burden on the power system, also adding significant mass to the system through batteries. The voltage ranges for the smallest, most powerful model motors

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 106 Dept of Aeronautics and Astronautics

have high-end voltages of 18-24 volts, which is a more reasonable parameter for the EMFFORCE system.

E.4.3 Motor Selection The selected motor is the Cobalt 625 Airplane Motor, provided by Astroflight, Inc. The motor requires a variable voltage of 6-18 volts. It is capable of providing a torque of 0.25 Nm with an applied current of 25 amps. This torque capability is more than sufficient for the EMFFORCE operational requirements. Noteworthy motor specifications are listed Table E.4-A and a photograph of the motor is shown in Figure E.4-A: Table E.4-A: Cobalt 625 Motor Specifications

Speed 971 RPM/Volt

Maximum Current 35 Amps

Shaft RPM 12,000 – 15,000

Weight 0.31 kg

Length 0.0635 m

Diameter 0.0427 m

Figure E.4-A: Cobalt 625

E.4.4 Determination of Required Power The power requirement for the motor depends on the voltage and current input to the system. The torque requirement for the motor drives the required current, while the voltage required is determined by operational speed of the motor. Equation E.4-9 gives the relationship for the motor’s torque, where k is the torque constant.

ki=τ Equation E.4-9

The provided torque constant for the Cobalt 625 motor is Aozink −

= 39.1. This yields a

required current for the motor of 10.2 amps. The total voltage required by the motor is a sum of the voltage needed to overcome the resistance in the armature and the voltage needed to overcome back electromotive force (EMF):

armBackEMFtot VVV += Equation E.4-10 The voltage due to back EMF is calculated using a design RPM for the flywheel of 2000 RPM. This is a design requirement and has inherent margin built into it. Equation E.4-11 gives the relationship for the voltage due to back EMF:

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 107 Dept of Aeronautics and Astronautics

Constant SpeedMotor RPMDesign

=BackEMFV Equation E.4-11

For the given motor and design RPM this gives a voltage due to back EMF of V 1.2=BackEMFV . The voltage needed to overcome the resistance in the armature is found using Ohm’s Law:

armarm iRV = Equation E.4-12 The resistance in the armature is given to be 0.093 Ω. This gives a voltage due to resistance in

the armature of V 95.0=armV . These calculations give voltage, current, and power requirements for the system:

W32A 2.10V 1.3

===

=

iVP i

Vtot

Equation E.4-13

E.4.5 Vendor Information The reaction wheel assembly motors were purchased from Astroflight, Inc. which is located at 13311 Beach Avenue; Marina Del Rey, CA. Astroflight can be reached by phone at (310) 821-6242.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 108 Dept of Aeronautics and Astronautics

F Coil and Containment Design and Manufacture (MW, JB)

F.1 Electromagnet Subsystem Requirement (MW) The electromagnet team is responsible for the design and construction of the electromagnets for the actuation system of each vehicle. The electromagnets will provide the forces and torques necessary for translational movement in the 2-D horizontal plane and for disturbance rejection. To demonstrate the concept of electromagnetic formation flight, the baseline maneuver will consist of a two-vehicle system performing a spin-up maneuver as illustrated by Figure F.1-A. In this figure, the two vehicles are represented as electromagnet dipoles in an initial perpendicular configuration. As current is applied to the electromagnets, forces and torques are induced as illustrated by the arrows in Figure F.1-B. Using a reaction wheel, these forces and torques are counteracted such that the dipoles begin to spin-up until they are aligned along a single axis in steady state rotation. Each vehicle will be floated across a smooth surface using compressed gas to reduce friction.

Figure F.1-A: Baseline maneuver. Two-vehicle electromagnet dipole system undergoing spin-up.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 109 Dept of Aeronautics and Astronautics

Figure F.1-B: Induced forces and torques on two dipoles.

The electromagnets must provide the forces and torques required to perform the baseline spin-up maneuver to a constant steady state angular rate of one rotation per minute, or six degrees of arc per second, at a separation distance of two meters measured from each vehicle’s center of mass. The vehicles are required to maintain this rotation rate for a minimum of three rotations. In order to fulfill these actuation system requirements, the electromagnet subsystem team considered several designs for the electromagnet coil.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 110 Dept of Aeronautics and Astronautics

F.2 Design History (MW) The original design for the electromagnet consisted of a ferromagnetic core made of steel wrapped with copper wire to produce the force and torque necessary to fulfill the system requirements. However, since the ability of the system to spin up is dependent upon mass, it is desirable to keep the mass as low as possible. Additionally, since the EMFFORCE satellite test-bed is demonstrating a concept that should be translatable to space application, a large, heavy steel core would not necessarily be the best option due to high launch costs and payload restrictions. A coreless option was then considered. The electromagnet team discarded the steel core and worked on resizing the copper coil such that it was able to produce the required force and torque for spin-up without the core material. However, the large copper coil could not satisfy the requirement due to the restriction on the amount of current that could safely be passed through the wire. Even with cooling systems, it would not have been feasible to use a coreless copper coil electromagnet because of the resistance of the wire creating a large amount of heat. The team then considered a new material to replace the copper that could carry higher levels of current. An electromagnet made of high temperature superconductor wire became the chosen alternative to the copper wire electromagnet coil. American Superconductor’s Bi-2223 reinforced high temperature superconductor wire is able to safely carry more than ten times the amount of current that copper can at temperatures below 110 K. Below this temperature, the superconductor wire has zero resistance allowing more than 100 amps of current to be passed safely through the wire. This amount of current made it feasible for the subsystem to produce the required force and torque necessary to spin up the system. However, since the superconductor wire must be kept below 110 K during the entire duration of the test, the superconductor wire adds the additional requirement for a coil containment system that keeps the wire below this temperature. Using the coreless superconductor coil as the choice for the electromagnet, the team began the final design and fabrication of the electromagnet subsystem.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 111 Dept of Aeronautics and Astronautics

F.3 Design Overview (MW) The design for the electromagnet subsystem consists of two perpendicular, vertically oriented coils made of high temperature superconductor wire. Two perpendicular coils are used to allow for variability in the direction of the magnetic field. Since the superconductor coils must operate at temperatures below 110 K, they are immersed in liquid nitrogen at 77 K for the duration of the test. The liquid nitrogen and coil are contained within a toroid-shaped casing, and the liquid nitrogen is replenished from a reservoir on top of the coil casings. Figure F.3-A shows the configuration of the perpendicular coils.

Figure F.3-A: Electromagnet Coil Design Overview.

0.67

0 m

0.83

5 m

Outer Coil

Inner Coil

g

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 112 Dept of Aeronautics and Astronautics

F.4 Electromagnet Coil Sizing (MW) The first task to be completed was the sizing of the electromagnet coil. In order to determine the size of the coil, the electromagnet team first calculated the strength of the coil necessary to meet the design requirements. To do this, the team considered the baseline spin-up maneuver of two vehicles to a steady state rotation of one rotation per minute. Each vehicle is modeled as a dipole. Figure F.4-A shows the two dipoles at a separation distance (s) and at dipole angles of (α) and (β). The two vehicles undergoing spin-up during the baseline maneuver are modeled as magnetic dipoles.

Figure F.4-A: Two Magnetic Dipoles.

Calculating the force in the radial (x) direction and the force in the tangential (y) direction, the following equations are obtained where (µo) is the permeability constant and (µA) and (µB) are the magnetic moments of the dipoles (Schweighart 2002):

Axial force:

( )βαβαµµµπ

sinsincoscos243

4 −=s

F BAox

Equation F.4-1

Tangential force:

( )βαβαµµµπ

cossinsincos43

4 +−=s

F BAoy

Equation F.4-2

S S

N N y

x β α

s

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 113 Dept of Aeronautics and Astronautics

The radial force due to the magnetic dipoles is required to counteract the centripetal acceleration

of the rotating vehicles. The tangential force provides the necessary angular acceleration (•

ω ) for the vehicles to spin up. These relations provide the following equations:

( ) ⎟

⎠⎞

⎜⎝⎛=−=

2sinsincoscos2

43 2

4sm

sF BAo

x ωβαβαµµµπ Equation F.4-3

( ) ⎟

⎠⎞

⎜⎝⎛=+−=

2cossinsincos

43

4sm

sF BAo

y ωβαβαµµµπ Equation F.4-4

Solving for the magnetic moment of a dipole and assuming that both vehicles have identical coils and masses and that β = 0°, the following equation is obtained where (m) is the mass of the vehicle and (ω) is the rotation rate of the system (Schweighart 2002):

21

425

42

332

⎟⎟⎟⎟⎟

⎜⎜⎜⎜⎜

⎛+⎟

⎠⎞

⎜⎝⎛

==

oBA

sm

µ

ωωπµµ

Equation F.4-5

This equation provides the instantaneous magnetic moments necessary to maintain a rotation rate (ω) for a vehicle of mass (m) at a separation distance (s) from another vehicle where the permeability constant (µo) is 4π * 10^-7. The mass estimate of the vehicle is approximately 20 kg. Using the set requirements for steady state rotation and separation distance and setting

angular acceleration (•

ω ) equal to zero, the required magnetic moment for one dipole is 2418 [A-m2]. In order to determine the size of the coil, the electromagnet team increased the mass estimate and separation distance requirement by a margin of 25% for safety. Calculating the required magnet strength for 25 kg vehicles at a separation distance of 2.5 meters, µA = µB = 4723 [A-m2]. Figure F.4-B shows the dependency of magnetic moment on mass and separation distance. The required magnetic moment for each dipole, in order to fulfill the baseline maneuver requirements for the nominal case and for the case with a 25% margin of safety factored into the mass and separation distance, is denoted by the dashed lines.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 114 Dept of Aeronautics and Astronautics

5 10 15 20 25 30

1000

2000

3000

4000

5000

Figure F.4-B: Magnetic Moment vs. Mass for 2.0 and 2.5-meter separation distances.

For the electromagnet coils, µ = nIA where n is the number of turns of the superconductor wire, I is the current, and A is the area enclosed by the coil. The current was set at 100 amps, which is a safe level of current that may be passed through the superconductor wire. Since there are two coils per vehicle, the outer coil was sized such that it exceeded the required magnetic moment for the system with margin while leaving enough room for the inner coil to be sized to meet the original requirement. The outer coil diameter was set at 0.835 m with 99 turns of superconductor wire. For these coil properties and 100 amps of current, µouter = 5421 [A-m2]. The inner coil diameter was set at 0.670 m with 120 turns of superconductor wire. For these coil properties and 100 amps of current, µinner = 4231 [A-m2]. At the diameters and number of turns set for the outer and inner coils, each coil requires the same length of superconductor wire and allows room for the coil casings to fit around each coil.

µ [A

-m2 ]

Mass [kg]

s = 2.5 m

s = 2.0 m

with margin

nominal

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 115 Dept of Aeronautics and Astronautics

F.5 Coil Wrapping (MW) Once the sizing for each coil was determined, the electromagnet team began fabrication on the first vehicle’s inner coil. The wire used for the electromagnet coil is Bi-2223 reinforced high temperature superconductor wire manufactured by American Superconductor. In order to prevent the coil from shorting out, the superconducting coil is layered with DuPont Kapton insulator tape with adhesive on one side of the tape. Figure F.5-A shows the dimensions of the superconductor wire, and Figure F.5-B shows the dimensions of the Kapton insulator.

Figure F.5-A: Reinforced High temperature superconductor wire.

Error!

Figure F.5-B: Kapton insulation tape.

Each coil consists of three individual coils of superconductor wire layered with insulator. This design allows for a more compact casing to be constructed around the coil than would be required for a single tall stack of the required number of wire turns. Figure F.5-C shows a cross-section and dimensions of both the outer and inner coils. The outer and inner coil stacks each contain 33 and 40 layers, respectively, of superconductor wire layered with Kapton insulator tape.

4.1 mm

0.3 mm

0.0254 mm 6.35 mm

Outer Coil

1.3 cm

Inner Coil

1.5 cm

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 116 Dept of Aeronautics and Astronautics

Figure F.5-C: Outer and inner electromagnet coil cross-sections

In order to wrap each coil stack, a spindle for the outer coil and another spindle for the inner coil were fabricated out of three layers of Plexiglas to match the inner dimensions of each coil. The superconductor wire and Kapton tape were layered onto the spindle as it was slowly rotated until each stack was complete. Figure F.5-D is a side-view of the wrapping assembly, and Figure F.5-E is a side-view of the spindle. The three layers of Plexiglas are held together by wing nuts that allow the coil stack to be removed. The spindle aligns the superconductor wire and Kapton tape during the wrapping process. The Plexiglas pieces are separated by removing the wing nuts. This allows the coil stack to be removed once it is finished.

Figure F.5-D: Side-view of the wrapping assembly.

Kapton Tape

Plexiglas Spindle

Superconductor Wire

Layered wire and Kapton tape

Plexiglas layers

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 117 Dept of Aeronautics and Astronautics

Figure F.5-E: Side-view of wrapping spindle.

F.6 Coil Testing (MW) One layer of the inner coil was tested to determine whether it exhibited superconducting properties below 110 K and to measure the magnetic field for comparison with the expected values from the model derived by Samuel Schweighart from the equations found on http://www.netdenizen.com/emagnet. The model for the field strength in the axial direction is given by Equation 6, and the model for the field strength in the radial direction is given by Equation 7 where (a) is the coil radius, (n) is the number of wire turns, (i) is the current, (r) is the radius of the measurement point, and (h) is the height of the measurement point. EllipticK denotes a complete elliptic integral of the first kind, and EllipticE denotes a complete elliptic integral of the second kind. In order to simplify the model, consider the following substitutions:

ar

=α a

h=β

rx

22

1 ⎟⎠⎞

⎜⎝⎛+⎟⎟

⎞⎜⎜⎝

⎛⎟⎠⎞

⎜⎝⎛+=

ax

arq

Equation F.6-1

The resulting equations for magnetic field strength in the axial and radial directions are:

⎟⎟⎠

⎞⎜⎜⎝

⎛⎥⎦

⎤⎢⎣

⎡+⎥

⎤⎢⎣

⎡⎟⎟⎠

⎞⎜⎜⎝

⎛−

−−=

qEllipticK

qEllipticE

qqain

B oaxial

ααα

βαπµ 44

41

2

22

Equation F.6-2

⎟⎟⎠

⎞⎜⎜⎝

⎛⎥⎦

⎤⎢⎣

⎡−⎥

⎤⎢⎣

⎡⎟⎟⎠

⎞⎜⎜⎝

⎛−

++=

qEllipticK

qEllipticE

qqain

B oradial

ααα

βαπ

γµ 444

12

22

Equation F.6-3

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 118 Dept of Aeronautics and Astronautics

The resistance of one layer of the inner coil at room temperature was measured at 0.37 ohms. The layer was then immersed in liquid nitrogen at 77 K, and the measured resistance was zero, indicating that the wire was superconducting at that temperature. Thirty amps of current were applied to the immersed coil, and magnetic field (or B-field) measurements were taken using a Gauss-meter. Figure F.6-A illustrates the experimental setup for the axial B-field measurements taken at varying radii, Figure F.6-B illustrates the setup for the radial B-field measurements taken at varying radii, and Figure F.6-C illustrates the setup for the axial B-field measurements taken at varying height.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 119 Dept of Aeronautics and Astronautics

Figure F.6-A: Axial B-field Figure F.6-B: Radial B-field Figure F.6-C: Axial B-field measurement at varying radii. measurement at varying radii. measurement at varying height.

The experimental data was plotted against the field strength model to determine how well the

model predicted the induced magnetic field.

Figure F.6-D is a plot of axial magnetic field strength at varying radii, Figure F.6-E is a plot of radial magnetic field strength at varying radii, and Figure F.6-F is a plot of axial magnetic field strength at the center of the coil at varying heights.

0.1 0.2 0.3 0.4 0.5 0.6

-10

10

20

30

Figure F.6-D: Magnetic Field in Axial Direction vs. Radius.

Inner Coil Layer

Gauss meter

Inner Coil Layer Inner Coil Layer

Gauss meter

Gauss meter

B [g

auss

]

Radius [m]

0.05 m

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 120 Dept of Aeronautics and Astronautics

0.1 0.2 0.3 0.4 0.5 0.6

10

20

30

40

Figure F.6-E: Magnetic Field in Radial Direction vs. Radius.

0.1 0.2 0.3 0.4 0.5 0.6 0.7

5

10

15

20

25

Figure F.6-F: Magnetic Field in Axial Direction vs. Height.

B [g

auss

]

Radius [m]

B [g

auss

]

Height [m]

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 121 Dept of Aeronautics and Astronautics

F.7 Containment System (JB)

F.7.1 Requirements: • The super conducting wire must be immersed in liquid nitrogen at all times during

operation • Insulate from the environment the wire and the liquid N2. A better insulation will allow a

slower boil off, which means less liquid nitrogen will be needed to maintain the required temperature, and thus the EM subsystem will be lighter, which is more desirable for overall design of the vehicles

• Stiff enough to support liquid N2 container, its own weight, and the weight of other components that will be attached to it. As shown in the diagram of the vehicle, the containment system is the main structure; therefore it needs to have attached points and be strong enough to support the weight of the different components

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 122 Dept of Aeronautics and Astronautics

F.7.2 Parts • 2 coil containments per vehicle. Manufactured and designed specifically for EMFF • 1 tank per vehicle. Manufactured and designed specifically for EMFF • 4 pipes per vehicle. 1 inch in diameter, 1 foot long made out of brass

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 123 Dept of Aeronautics and Astronautics

F.7.3 Design and Manufacturing

F.7.3.1 Coil containment In order to hold the coils and the liquid nitrogen that surrounds it, and achieve the desired insulation, STYROFOAM extruded polystyrene insulation was used to build a toroidal shape container. The size constraints come from the coil Figure F.7-A. The wire goes through the center of the toroid shaped container.

Figure F.7-A: Coils on the Vehicle

Since there are two coils, which need to be perpendicular to each other, one of the containers is small enough fit inside the other. The dimensions of the coils are shown in Figure F.7-B and Figure F.7-C, respectively.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 124 Dept of Aeronautics and Astronautics

Figure F.7-B: Cross Section of the Inner Coil (cm)

Figure F.7-C: Cross Section of Outer Coil (cm)

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 125 Dept of Aeronautics and Astronautics

In order for the liquid nitrogen to flow better through the container, spacers were included on the sides of the wire. These are shown in the cross section figures for the coils. Figure F.7-D shows the details of the spacers on the side and bottom for the male part of the container. Another part that has the mirror shape of this one, attaches to the top creating more space for the liquid N2.

Figure F.7-D: Spacers for the Male Part of the Container The manufacturing of the containers is a time consuming process. For every container tested there at least six to ten hours of only manufacturing time. There is also time to epoxy the different parts, which is about an hour and finally the curing time, which is from sixteen to 24 hours for every layer of epoxy. The containers were built in two parts, each part having had four pieces each. These pieces were made in a milling machined programmed in mastercam 9. The first part was the “Male” piece and the second one was the “Female” piece, since they were negative of each other. After putting each part together with epoxy the super conducting wire was put into the female piece, where all the extra wiring took place. Before epoxing the two halves together, tests were performed to make sure that current could flow through all the wires. Once the two main parts’ assembly had dried, fiberglass and cryogenic epoxy were applied to the outside for leak proofing and to make the structure stiff. Finally, the containers have to be thermo cycled about ten times, in order to stress relieve the foam. This causes many cracks on the foam, but once it has gone through enough number of cycles it will stop cracking and leaking.

F.7.3.2 Tank The purpose of the tank is to hold liquid nitrogen, in order to keep the wires immersed as the nitrogen boils off. The volume the tank has to hold is directly related to the amount of time the system is expected to operate. Based on boil off testing on the coils and the fact that the limiting

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 126 Dept of Aeronautics and Astronautics

factor for operational time is the air carriage system, which can run for 8 minutes, the tank was designed to carry enough nitrogen to keep the coils immersed for 10 min. If at some point the desired volume is increased, the current design for the tank allows to simply add another layer of foam and the volume would be increased by whatever thick ness this new layer has. This is clearer in Figure F.7-E.

Figure F.7-E: Area of the Tank

The tank was constructed in a similar manner as the coils containment. A foam frame was made and epoxied together and fiberglass with epoxy was applied to the outside. The foam frame was composed of a square base and two square layers of the same size but the inside was cut off, leaving a squared ring. Finally, 4 pipes were connected to the coils (2 for each coil) as shown in Figure F.7-F.

Figure F.7-F: Tank

16 inches

16 inches

12 inches

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 127 Dept of Aeronautics and Astronautics

G Metrology System Design (AA)

G.1 Subsystem Outline The purpose of the metrology subsystem is to determine the separation distance and relative orientation of the craft. The data will be used to control the system and stored for analysis of the system performance. The primary purpose of the metrology system is to provide an input for the control algorithm. The data will be used to maintain control of the cluster. This purpose is the main source of the system requirements.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 128 Dept of Aeronautics and Astronautics

G.2 Requirements The metrology system is required to determine the position and orientation of the vehicles. The metrology system is also required to determine the angular rate of each vehicle. This data will be used to control the system and recorded for analysis. Specifically the metrology system must:

• Determine the separation distance of the vehicles to within 1cm • Determine the bearing angle between vehicles to within 5 degrees • Work at a maximum separation distance of 4m • Return data at a rate of 1 Hz.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 129 Dept of Aeronautics and Astronautics

G.3 Current System Design The current metrology system is legacy technology modified to suit our needs. The current design for the metrology system is a hybrid of the system used for project SPHERES and the system utilized by the Electronic Ink Corp. in their Mimio Electronic whiteboard. The design of the receivers is taken directly from SPHERES, since it had proven effective on that project and met our current system requirements. The transmitter is based on the design of the Mimio pen (transmitter). The Mimio transmitter proved to be more effective for location in 2D a plane (where as the SPHERES system was designed to work in 3D space). The original designs have been modified to suit the specific needs of project EMFFORCE, however, it can be assumed that any part of the design which is not explicitly described below is based solely on legacy technology. The metrology system uses triangulation of emitted ultrasonic signals to determine the location of the vehicles. Infrared emitters and receivers facilitate timing of the ultrasonic pulses. Each vehicle will be equipped with three omni-directional ultrasonic receivers, 1 omni-directional ultrasonic transmitter, and an array of infrared transmitters and receivers (to cover 360 degree line of sight). In this document, omni directional is taken to mean that the transmitters emit signals of the same amplitude and phase in all directions in the horizontal plane (360 degrees) and the receivers can sense a signal from any direction in a plane. This is not strictly “omni directional,” but since the test bed operates in 2D, the term is adequate. During one cycle of the sensing system, each vehicle will take turns emitting and receiving pulses and then calculate the position of the other vehicles by triangulation. The first vehicle will first emit an infrared pulse followed by an ultrasonic pulse at a known time later. The other two vehicles will first receive the infrared pulse followed by the ultrasonic pulse at each of the three receivers. The time difference between the reception time of the IR and Ultrasonic pulses will give time of flight for the ultrasonic pulse. This will be used to determine the distance of the transmitter from each of the receivers. A simple calculation will give the position of the transmitter. After the vehicles have the position data for the first vehicle, the second will take its turn to emit followed by the third. There is an inherent delay in this system. The ultrasonic pulse must be allowed to leave the test area before another can be emitted otherwise the first pulse might interfere with measurement of the subsequent pulses. Given the speed of sound at standard conditions and the current geometry of the system, the metrology team has calculated that it will require 23 milliseconds for a pulse to leave the test area before the next can be sent. As a result, a three-vehicle system will require 69 milliseconds to determine the orientation of all three vehicles. This is a delay inherent to the physics of the system and cannot be significantly changed. From this approximation and added margin for known and unknown factors, it is currently approximated that the metrology system will operate at 1 Hz.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 130 Dept of Aeronautics and Astronautics

G.4 Hardware Component Design

G.4.1 Structural Support The Structural support is designed to keep the other components in the proper orientation. It is necessary to keep the relative positions of the receivers fixed in order to calculate the position and orientation of the vehicle. Since the positioning of the receivers is so important, the metrology designed the structural support independently of the structure of the rest of the vehicle. The metrology system works by using differences in reception time at each of the receivers, thus it is important to keep them as far apart as possible. If the receivers are close together the difference in reception times will be very small. If the receivers are farther apart the average difference will be greater. Since errors in reading the receivers should be independent of receiver location, the greater difference between the reception times will make the errors less significant. The extent of this effect has not been calculated directly. The general assumption during design was that the receivers should be as far from the center of the vehicle without overhanging the edge of the vehicle. The structural support is attached to the vehicle using Velcro. For accurate position and angle measurement, the system needs to be aligned with the axis of rotation and center of mass of the vehicle (it was assumed that they would be in the same place, directly below the center of the support). It was assumed that axis of rotation might be hard to find or might change due to design changes so adjustments might be necessary. Velcro was used to make small adjustments easy. The support structure of the metrology system is a large Y cut from a single sheet of 1/8-inch thick aluminum stock (a diagram is shown in Figure G.4-A). The structure was cut using the water jet. The legs each extend 0.38m from the center and are offset from each other by 120 degrees. The structure is attached to the top of the vehicle using Velcro. Specifically, the structure is attached to the lid of the cryogenic storage tank. The receivers attach at the ends of the beams and the transmitters attach at the center using Velcro. The Velcro is used for ease of adjustment.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 131 Dept of Aeronautics and Astronautics

Figure G.4-A: Design of structural support to hold transmitter and receiver circuits.

G.4.2 Receivers The ultrasonic and infrared receivers are mounted together on circuit boards at the ends of the support structure. The receivers consist of an ultrasonic and 2 infrared receivers mounted on a circuit board and a reflective cone. The board will amplify the ultrasonic signal, rectify it, and run it through a comparator to return a digital signal. The reflective cone will reflect ultrasonic waves coming from any direction into the ultrasonic receiver. This is to make unidirectional receivers into omnidirectional receivers. Reflecting the ultrasonic wave off the cone decreases the amplitude of the wave and thus will decrease the maximum range of the system. However, at this time, the range of metrology system exceeds the requirements so the loss due to reflection is negligible. The receiver circuit consists mostly of amplifiers for the ultrasonic receiver. The output of the ultrasonic emitter is limited so the range of the ultrasonic components must be accomplished at the receiver. The opposite is true of the infrared system. The receivers do have a high and low setting, however the high setting picks up the lights in the lab so the IR receivers must be used on low sensitivity. Range of the IR system is determined by the output of the transmitter (see below). Initially, the boards were to be printed circuits (see Sections 0 and G.9), however when the project was scaled back from three vehicles to two vehicles, it became more time efficient to build the circuits by hand. This has resulted in some variability in the boards but they all seem to work within requirements. The only method of adjusting the receivers is a variable resistor built in to the comparator on the receiver circuit. This resistor sets the sensitivity of the comparator and thus the sensitivity of the receiver.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 132 Dept of Aeronautics and Astronautics

The 10K pot sets the voltage to pin 13, which in turn determines the sensitivity of the comparator. (See Figure G.4-B below) If the voltage at pin 13 is set too low the receiver will never detect a signal (case 1 in Figure G.4-B). If the voltage is set too high, the receiver will stay on constantly due to background noise (case 4). At the proper setting the output of the receiver (pin 14) will stay low, ground, until the receiver detects an ultrasonic pulse at which point the pin will change to high, 5 volts (case 2). When the signal stops, pin the output will drop back to low. If the voltage at 13 is set just over the correct value, the signal at 14 will be inverted, that is the voltage will stay high until it detects a falling signal which will make pin 14 drop to low before returning to high (case 3).

Figure G.4-B: US receiver output calibration. Output of US receiver for a constant pulsing signal at various sensitivities.

To calibrate a receiver, place the ultrasonic transmitter at the minimum operational range so that the signal will be the strongest signal encountered during operation. Turn on the transmitter and leave it pulsing. Measure the output of the receiver (pin 14 or the US output line) with an oscilloscope. Adjust the 10K pot until the signal almost switches to the oversensitive (pin stays high) position. For maximum range, set the sensitivity as high as possible without changing to the “always high” case. If maximum range is not required, it is suggested that the receivers be set on lower sensitivity. There is no clear cutoff between the sensitivity regimes. The appropriate voltage at pin 13 varies depending upon whether you are starting from a lower voltage or a higher voltage. The reflective cones used on the ultrasonic receivers are taken directly from parts donated by Mimio. The metrology team had originally decided to construct cones since there were not enough of the Mimio cones to supply three vehicles. De-scoping of the project (from three vehicles to two vehicles) made possible to use the Mimio cones. Section G.10 includes the preliminary design for custom made cones. Section G.10 is included in case more than 6 receivers are needed, or in case the Mimio cones are broken or lost. The cones are not currently attached to the boards (they are simply placed on top). While this design is not ideal, it is sufficient. A more permanent attachment should eventually be found. The receiver circuit boards have been mounted on pieces of Plexiglas to insulate the connections from the aluminum structural support. The boards are tied to the Plexiglas using small pieces of bare wire. This is an inelegant but effective solution. The boards are attached to the structure

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 133 Dept of Aeronautics and Astronautics

via strips of Velcro. The Velcro is adhered to the bottom of the Plexiglas. Velcro was chosen for ease of minor adjustments.

G.4.3 Transmitters Each vehicle has a single transmitter unit placed at the center of the structural support. The transmitter emits both infrared and ultrasonic signals that can be detected by the receivers on the other vehicle(s). The current design calls for an infrared pulse followed by an ultrasonic pulse but the transmitter is capable of sending either signal at any time. Both channels are designed to take pulse inputs. Neither channel should ever receive a constant high signal or the circuit could overheat. The ultrasonic transmitters used for the metrology system were graciously donated by the Electronic Ink Corp (See Section G.9). They are the omni directional units used on the pens of the Mimio Electronic Whiteboard System. The top of a Mimio pen is used on each transmitter unit. The pen contains both the ultrasonic emitter and an array of infrared emitters. The emitters proved to be inadequate for our purposes so they are not used. The two extra wires coming from the Ultrasonic emitter are for the IR emitters. They should be left disconnected. Only the red and white leads are used and they are connected to the leads of the transformer. The design of the ultrasonic emitter circuit is taken directly from the designs provided by Mimio. The mosfets controlling the emitters have been replaced with the ultrafetts, which were left over from the power subsystem. The signal to the ultrasonic emitter should be a low signal that pulses to high. The ultrasonic emitter is capable of sustaining a constant (oscillating 40kHz) signal, but not at the voltage used to power it. The emitter currently runs at its max pulse voltage of 300 V. To run continuously it must be scaled down to 150 V. The infrared transmitter consists of four arrays of PDI-E804 high-power infrared emitters (see Figure G.4-C). Each array contains six emitters. The four arrays will ensure a detectable signal is sent in every direction in the horizontal plane. The transmitter would probably meet the range requirements with as few as four emitters per array, but it was more time efficient to use more emitters to ensure the system would work.

Figure G.4-C: US40KT-01 40 kHz Omnidirectional Ultrasound Transmitter (left). PDI-E804 High-Power Infrared Emitters (right).

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 134 Dept of Aeronautics and Astronautics

G.4.4 Rate Gyros The metrology system utilizes rate gyros which were graciously donated by project SPHERES, specifically, the BEI Gyrochip II. The axis of the gyro must be parallel to the axis of rotation of the vehicle and the gyro will connect to the power system and to the avionics tattletale. Otherwise, the gyro can be placed anywhere on the vehicle. A simple resistor-capacitor (RC) circuit has been added between the gyro and the tattletale to reduce high frequency noise. The noise seems to come from the reaction wheel motor but it is difficult to determine exactly. The values of the RC circuit are a 16000-Ohm resistor and a 1-microfarad capacitor. These values were calculated assuming a sample rate of 10 Hz. This gave a value of RC = 1/60. The resistance was chosen to be well under the input resistance of the tattletale (which was unknown but assumed to be around 10^6 Ohms). The exact values were chosen based on what was readily available in the lab. The connector for the rate gyro board has four terminals. There are two output leads; one is the direct output before going through the RC circuit. The other is the corrected output, which is first filtered by the RC circuit. The planned stationary beacon will not be utilized. Functionally, it would resemble the transmitters on each vehicle. The beacon would consist of one transmitter unit mounted on a stand that is the same height as the vehicles. The stationary beacon would provide data that could be used to determine the inertial position of the vehicles. The current system design does not call for a stationary beacon as the vehicle does not have inertial control authority. This requirement may change, but it is assumed that the stationary beacon will not be built. This section has been retained for the sake of completeness.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 135 Dept of Aeronautics and Astronautics

G.5 Testing/Verification

G.5.1 Hardware Testing The following hardware tests have been completed. The results are summarized below. Range test A transmitter was placed near a receiver and slowly moved away until the signal was undetectable. An oscilloscope was used to read outputs of infrared and ultrasonic receivers. The range of the transmitter and receivers is roughly four meters. Time of flight measurement test An oscilloscope was used to read outputs of infrared and ultrasonic receivers. The time difference between reception of infrared and ultrasonic signals was compared to the distance between receiver and transmitter. The relation proved to be linear over the test range. Timing error due to angular offset This test consisted of two parts. First the transmitter was rotated to verify that transmitter orientation caused no variation in signal reception. Then the transmitter was placed one meter from receiver at various positions around the receiver. The time of flight was compare for each position to determine if angular position caused any change in reception time. The time of flight did not vary with angle. Thus there seems to be no effect on range determination due to angles changes.

The tests described above were preliminary tests to verify the functionality of the metrology hardware. Similar tests were run with the full hardware setup running on the metrology software. The data for these tests is included in the metrology software section.

G.5.2 Interfaces

G.5.2.1 Communications With the current design, each vehicle is only able to determine its own position and orientation relative to the other vehicles. Therefore, the angular orientation of the other vehicles is transmitted over the communications system so the control algorithm will have all of the information required to control the vehicles.

G.5.2.2 Avionics The hardware for the metrology system is connected to the avionics board. The avionics board contains a tattletale board dedicated to the metrology system. There are two output pins on the avionics board to the transmitter. The outputs include one ultrasonic out and one IR out. There are six inputs on the avionics board from the metrology subsystem. The inputs on the avionics board include three infrared inputs and three ultrasonic inputs. All of these pins are connected to ribbon cable, which connects to the metrology system. There is an OR-gate chip on the avionics board that was intended to combine the signals from the infrared receivers. The gate proved unnecessary and may have been the cause of some of the noise in the system. The chip has been

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 136 Dept of Aeronautics and Astronautics

removed and replaced by wire that connects all of the Infrared inputs. The IR input pin stays high normally and a signal received by any one IR receiver will set the IR input pin low.

G.5.2.3 Structures The metrology subsystem must be mounted on the vehicles in such a way that it has an unobstructed 360-degree view so that it can locate the other vehicles. Obstructions will make “blind spots” where the other vehicles will be undetectable. To prevent blind spots, the metrology system is mounted on top of the vehicle. The support structure is attached to the top of the liquid nitrogen tank using Velcro. Again, Velcro was used for ease of adjustment.

G.5.2.4 Power The metrology system requires five-volt DC power and a ground line. The current draw should be minimal. The metrology system is connected to the power system via ribbon cable. All of the power and ground leads to each component of the metrology system have been soldered together so that only one power and one ground pin are required. The power leads are part of the same cable as the signal leads.

G.5.3 Subsystem Mass

Table G.5-A: Mass Budget.

Component Mass each (g) Mass per Vehicle (g) Reflective Cone 40 120 Receiver board* 38 114 Transmitter Board* 78 78 Structure 514 514 Rate Gyro 48 48 Vehicle Total 874

*Including Plexiglas insulator/support and Velcro attachment The masses above were determined by weighing the components on a digital scale. The masses of each component vary (especially the circuit boards). The values above represent the highest value of the measured components. The variations were usually only a few grams.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 137 Dept of Aeronautics and Astronautics

G.6 Receiver Cirrus Layout

Figure G.6-A: Receiver Mounted on Structure support (Left) and Top View of Receiver Circuit with Cone and Wires Disconnected (Right)

Figure G.6-B: Metrology System mounted on Vehicle

Reflective Cone

IR Receivers

US Receiver

Pow US Gnd IR

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 138 Dept of Aeronautics and Astronautics

IR Emitter Array

US Emitter

US Emitter Support

IR Emitter Array

IR Emitter Array

Pow

US

Gnd

IR

G.7 Transmitter layout

Figure G.7-A: Transmitter board mounted on structural support

Figure G.7-B: Detail view of Transmitter

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 139 Dept of Aeronautics and Astronautics

G.8 Receiver Circuit Design

Figure G.8-A: Receiver Circuit Schematic

Note: this Diagram is incorrect since the OR-Gate is no longer used. Also the IR receivers connect to pin 4 and ground connects to pin 3.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 140 Dept of Aeronautics and Astronautics

G.9 Transmitter Circuit Design

Figure G.9-A: Transmitter Circuit Schematic

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 141 Dept of Aeronautics and Astronautics

Figure G.9-B: Transmitter Circuit Schematic

Note: Figure G.9-B is incorrect because the IR output is on 4 and ground connects to pin 3. The original OrCAD file for this circuit has been lost due to computer error.

G.10 Reflective Cone Design The current metrology system utilizes reflective cones (see Figure G.10-A) taken directly from a Mimio Electronic whiteboard system. The cones were graciously donated by The Electronic Ink Corporation. We currently have enough cones for 2 metrology systems with one backup. However, we originally planned to construct our own cones. This section gives information on how to construct such a cone in case more metrology systems are required or replacement parts are needed. Alternately, it might be more efficient to purchase a Mimio system and use it for parts (though this seems wasteful). The cones come from the receiver (base unit) of the Mimio system.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 142 Dept of Aeronautics and Astronautics

Figure G.10-A: Reflective cone. Ultrasonic signals coming from any direction reflected into the receiver.

The shape of the cone is defined by rotating a portion of a parabola about the y-axis. The constants of the equation were determined using measurements of the reflective cones used in the Mimio Electronic Whiteboard system. The equation of the parabolic section defines the shape of the side of the reflective cones:

mmxmmxmmxmmy

390)906.4)(059.7(42

=→=

+=

Equation G.10-1

This equation was calculated using the measurements in Figure G.10-B. The measurements were taken from a Mimio cone using digital calipers.

Figure G.10-B: Reflective cone measurements. Measurements used to calculate the equation of the cone.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 143 Dept of Aeronautics and Astronautics

H Structures and Packaging (GG, TS) The packaging design represented the main task for the Structures team. The Structures team had to collect all of the necessary physical requirements for each subsystem and then feasibly and efficiently pack all these subsystems together. In order to feasibly and efficiently pack all the EMFFORCE subsystems successfully, the Structures team used a CAD modeling tool, as well as mock subsystems made out of paper, cardboard, and other simple materials. After finding a feasible configuration for the subsystems, the Structures team designed all of the attach points to ensure each subsystem’s physical requirements were met.

H.1 Physical Packaging Requirements (GG) The requirements surrounding the packaging include:

• Physical requirements of all subsystems o Metrology: 360 degree unobstructed view o Communications: vertical antenna towards top of vehicle o Reaction Wheel: placed at center of electromagnetic force o Electromagnet: EM batteries must be physically close (within 15 cm) of EM

power input leads o Vertical CO2 tank orientation for gas carriage gas supply

• Packaging must be feasible

o Maintain rotational symmetry, keep center of mass to within 1cm of axis of rotation

o Keep mass towards bottom of vehicle for stability o Attach points must withstand forces exerted on them o Allow for easy replacement of consumables (batteries, liquid nitrogen, CO2

tanks) o Keep mass and moment of inertia as small as possible (GG)

H.1.1 Power (TS) The physical requirements for the power subsystem on-board each vehicle are as follows:

• 1 Voltage Regulator power board • 2 Electromagnet power boards • 1 Reaction Wheel power board • 3 on/off switches for power boards (EM-1, EM-2, RW) • 1 AA-cell battery pack (consisting of 8 or 16 AA batteries) • Wires to connect Voltage Regulator board to AA batteries and other subsystems • 3 D-cell battery packs for EM (each consisting of 3 D-cell batteries in series) • 1 D-cell battery pack for RW (consisting of 4 D-cell batteries in series)

Optional components: • 1 small fan for each EM, RW power board • 1 extra D-cell battery pack for RW (placed in series with existing battery pack)

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 144 Dept of Aeronautics and Astronautics

H.2 Packaging Design (GG) The packaging design is comprised of a list of components and a plan for attaching them together into the EMFFORCE vehicle test-bed.

H.2.1 System Components The Structures team needed to develop a design to physically package the following components:

1. Two electromagnet rings of median diameter 890mm a. Super-conducting rings are encased in foam toroid containers with a liquid

nitrogen flow for cooling. These rings must be orientated perpendicularly. 2. Reaction wheel assembly consisting of

a. Cylindrical motor approximately 75mm tall and 50mm in diameter b. Reaction wheel approximately 20mm tall and 440mm in diameter

3. Power subsystem that includes a. 15 D-cell batteries for actuation b. 16 AA-cell batteries for electronics c. Three power boards approximately 100mm by 50mm by 20 mm

4. Avionics board approximately 70mm by 160mm 5. Metrology subsystem

a. Three sensors need an unobstructed 360-degree view of the surroundings and must lie in the same plane as the metrology transmitter. The metrology transmitter must also have an unobstructed view of each sensor.

6. Communications board approximately 20mm by 30mm with antenna at top of vehicle 7. Liquid nitrogen container for excess cooling liquid 8. Air Carriage system

a. Three pucks at base of vehicle b. Upright tank approximately 230mm tall submersed in a cool water bath

H.2.2 Attach Points and Assembly The CAD model proved useful in designing the attach points and finalizing the packaging geometry. Figure H.2-A is the CAD drawing of the EMFFORCE vehicle illustrating the layout packing methods and describing attach points. Figure H.2-B is a picture of the EMFFORCE vehicle illustrating the electronics mount.

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 145 Dept of Aeronautics and Astronautics

Figure H.2-A: Attach points.

Also not pictured in the above figure are the electronics boards and tank, which are seen in the photograph below.

Figure H.2-B: Electronics mount.

Metrology Transmitter and Communications Board RWA cross brace attaches with L shaped eyelet brackets

Electronics batteries and actuation batteries (not pictured) attach with Velcro

Metrology structure attaches to LN2 container with Velcro

Electromagnet rings attach with specially designed U shaped

braces.

Electronics mount

Tank is mounted on base plate behind electronics mount

U shaped braces used to mount electromagnets

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 146 Dept of Aeronautics and Astronautics

The current packaging design of the subsystems utilizes a spherical volume created by the two electromagnets to package the avionics board, power boards, electronics batteries, and reaction wheel assembly. The spherical volume attaches to a base plate that provides the planar area needed to float on the flat floor. This base plate was specially designed to attach to four points on the electromagnets and to three air pucks attached at 120-degree separation angle. Figure H.2-C is a picture of the base plate, the electromagnets attach at the struts and the pucks attach on the circular section. The electromagnets attach with U-shaped braces specially designed to the correct dimensions, see Figure H.2-D. The air carriage pucks must stay parallel to the flat floor even if the base plate for some reason is not parallel. Because of this, the pucks attach to the plate with springy washers that give the three pucks the ability to maintain planarity. The holes in the plate represent the attachment points. The outer most diameter of the base plate is 480mm.

Figure H-3: Circular Base Plate

Figure H.2-C: Base plate.

Figure H.2-D: U-shaped brace.

Puck attachment point

Electromagnet ring attachment point

Hose clamp fastening ring to brace

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 147 Dept of Aeronautics and Astronautics

The actuation batteries for the vehicle sit on the circular base plate at the bottom of the vehicle. This helps to keep the mass toward the bottom of the vehicle for stability, and also allows the batteries to be placed near the power leads to the electromagnets. The actuation batteries as well as the electronics batteries that are located inside the spherical volume at the bottom most point, are all secure in place with Velcro. This method, which allows for easy removal and replacement, is favorable to the power subsystem because of the need to continually replace batteries between each test. A cross-shaped brace will attach to four planar points on the rings to support the motor for the reaction wheel, and ultimately the whole reaction wheel assembly. A Plexiglas plate will hang vertically from the longer strut of the RWA brace and act as the mount for the avionics board as well as the three power boards. Figure H.2-E shows a CAD drawing of the electromagnet rings and RWA brace as well an actual photograph of the rings, with the RWA and Plexiglas electronics mount in place. The larger electromagnet has an outer diameter of 798mm; both electromagnets have a cross-sectional diameter of 80mm. The braces are manufactured from one-fourth inch aluminum sheet metal.

Figure H.2-E: RWA Cross brace across electromagnet rings.

A modified RWA mount may also be implemented to help keep the electromagnets perpendicularly aligned. This mount is photographed in Figure H.2-F.

Figure H.2-F: RWA modified mount.

The liquid nitrogen container sits on top of the rings where gravity allows the liquid nitrogen to flow into the toroid electromagnet containers and cool the coils (see Figure H.2-A). Above this container sit the metrology sensors on a large Y-shaped structure at whose center point sits the metrology transmitter. The communications board then sits on top of metrology transmitter making the antenna the highest point of the system.

565 mm

740 mm

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 148 Dept of Aeronautics and Astronautics

Attachment points were designed as specially manufactured brackets that permanently attach to the foam rings with a cryogenic epoxy. The epoxied brackets and foam ring are then wrapped in fiberglass strips for added strength. Brackets like the once pictured in Figure H.2-G hold the cross-braces for the avionics and RWA subsystems. The metrology structure attaches to the lid of the LN2 container with Velcro. Below is a picture of an L-bracket attached to a foam ring as well as to a cross-brace. Note the oval-shaped holed in the L brackets to account for the expansion and contraction of the electromagnets.

Figure H.2-G: L-brackets attached to foam ring and cross-brace.

Because tests have shown that magnetic interference will most probably not be present on the EMFFORCE vehicles, the current packaging design does not include the use of shielding. However if magnetic shielding becomes necessary, implementation will consist of wrapping the electronics components in the shielding foils obtained from MuShield, a magnetic field shielding manufacturer.

H.2.3 Attach Points Parts List Attach Point Part Material Method of Manufacture Base Plate

¼” thick 6062 aluminum sheet metal

Cut on OMAX operated waterjet cutter

RWA Mount

¼” thick 6062 aluminum sheet metal

Cut on OMAX operated waterjet cutter

U Shaped Braces

½” thick 6062 aluminum sheet metal large hose clamps

Cut on OMAX operated waterjet cutter. Hose clamp attachment holes drilled and tapped to 6-32 specifications using drill press. Steel hose clamps cut in half using Dremel

L Brackets

1/8” thick 5051 aluminum sheet metal

Cut on OMAX operated waterjet cutter, bent at 90 degrees on brake.

Plexiglas Electronics Mount 1/8” thick Plexiglas Cut on bandsaw

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 149 Dept of Aeronautics and Astronautics

I Code

I.1 Control Test Code (LS, AB)

I.1.1 Test Case 1 Code

%r=0.1; % Effective Radius [m] %m=2; % Estimated Body Mass [kg] %I=0.5*m*r^2; % Estimated Inertia [kg-m^2] I = 1; % Estimated Inertia [kg-m^2] A=[0 1 ; 0 0 ]; B=[0 ; 1/I]; lamda=1; rho=lamda/4; type=input('Input case(in quotes)'); % 0 for Regulator, 1 for Slew to Reference switch type case 'a' Rxx=[1e-5 0 ; 0 lamda]; Ruu=rho; [K,S,E]=lqr(A,B,Rxx,Ruu) case 'b' n=1e-2; Rxx=[lamda 0 ; 0 lamda/1000]; Ruu=rho; [K,S,E]=lqr(A,B,Rxx,Ruu) C=[n^3 1]; D=0; G = B; H = 0; sys=ss(A,[B G],C,[D H]); [Kest,L,P]=kalman(sys,n,n,n) end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 150 Dept of Aeronautics and Astronautics

I.1.2 Test Case 2 Code clear all; mu_b1 = 100*40*(.75/2)^2*pi; %Guess at value mu_b2 = 1/10*mu_b1; %arbitrary decision mu_0 = 4*pi*1e-7; ma = 15; %Estimate in kg Ia = 1; %Inertia of a and b in z direction Ib = 1; %Change this!!!! r = 2; %separation distance in meters n = 1e-5; rho = 1/4; %weighting factor c = input('Which case(in quotes)'); A = zeros(8); A(1:4, 5:8) = eye(4); B = zeros(8,4); B(5,1) = -15*mu_b1*mu_0/(2*pi*r^4*ma); B(5,2) = 15*mu_b2*mu_0/(4*pi*r^4*ma); B(6,1) = 15*mu_b2*mu_0/(4*pi*r^4*ma); B(6,2) = 15*mu_b1*mu_0/(4*pi*r^4*ma); B(7,1) = -mu_b2*mu_0/(pi*r^3*Ia); B(7,2) = -2*mu_b1*mu_0/(pi*r^3*Ia); B(7,3) = 1/Ia; B(8,1) = -2*mu_b2*mu_0/(pi*r^3*Ib); B(8,2) = -mu_b1*mu_0/(pi*r^3*Ib); B(8,4) = 1/Ib; switch c case 'a' %two vehicles, 1 fixed, disturbance rejection A=A([1:6], [2:7]); B=B([2:7], [1:3]); Q = n*eye(6); Q(4:6, 4:6) = eye(3); R = diag([rho, rho, rho/2]); [Ka, S, E] = lqr(A, B, Q, R); Ka case 'b' %two vehicles, 1 fixed, tracking A=A([1:6], [2:7]); B=B([2:7], [1:3]);

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 151 Dept of Aeronautics and Astronautics

Q = n*eye(6); Q(1:3, 1:3) = eye(3); R = diag([rho, rho, rho/2]); [Kb, S, E] = lqr(A, B, Q, R); Kb case 'c' %two vehicles, both free, disturbance rejection Q = n*eye(8); Q(5:8, 5:8) = eye(4); R = diag([rho, rho, rho/2, rho/2]); [Kc, S, E] = lqr(A, B, Q, R); Kc case 'd' %two vehicles, both free, tracking Q = n*eye(8); Q(1:4, 1:4) = eye(4); R = diag([rho, rho, rho/2, rho/2]); [Kd, S, E] = lqr(A,B,Q,R); Kd end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 152 Dept of Aeronautics and Astronautics

I.1.3 Test Case Three Code clear mu_b1 = 100*40*(.75/2)^2*pi; %Guess at value mu_b2 = 1/10*mu_b1; %arbitrary decision mu_0 = 4*pi*1e-7; ma = 15; %Estimate in kg mb = 15; %Estimate in kg mc = 15; %Estimate in kg Ia = .5*ma*(.75/2)^2; %Inertia estimates of a and b in z direction Ib = .5*mb*(.75/2)^2; %Inertia estimates of a and b in z direction Ic = .5*mc*(.75/2)^2; %Inertia estimates of a and b in z direction r_ab = 2; r_bc = 2; n = 1e-5; c = input('Which case(in quotes)'); A=zeros(14); A(1:7,8:14)=eye(7); B=zeros(14,7); B(8,1:2)=(15*mu_0/(2*pi*ma*r_ab^4))*[-mu_b1 mu_b2/2]; B(9,3:4)=(15*mu_0/(2*pi*mc*r_bc^4))*[-mu_b1 mu_b2/2]; B(10,1:2)=(15*mu_0/(4*pi*ma*r_ab^4))*[mu_b2 mu_b1]; B(11,3:4)=(15*mu_0/(4*pi*mc*r_bc^4))*[mu_b2 mu_b1]; B(12,1:2)=(-mu_0/(pi*Ia*r_ab^3))*[mu_b2 2*mu_b1]; B(13,1:4)=(-mu_0/(pi*Ib))*[2*mu_b2/(r_ab^3) mu_b1/(r_ab^3) 2*mu_b2/(r_bc^3) mu_b1/(r_bc^3)]; B(14,3:4)=(-mu_0/(pi*Ic*r_bc^3))*[mu_b2 2*mu_b1]; B(12,5)= 1/Ia; B(13,6)= 1/Ib; B(14,7)= 1/Ic; switch c case 'a' %test case a is three vehicles with the center fixed doing distrubance rejection rho = 1/4; A=A([1:5 7:12 14], [1:5 7:12 14]); B=B([1:5 7:12 14], [1:5 7]); Q=n*eye(6); Q(7:12,7:12)=eye(6); R=diag([rho rho rho rho rho/2 rho/2]);

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 153 Dept of Aeronautics and Astronautics

[Ka, S, E] = lqr(A, B, Q, R); Ka case 'b' %test case b is three vehicles with the center vehicle fixed doing tracking rho = 1/4; A=A([1:5 7:12 14], [1:5 7:12 14]); B=B([1:5 7:12 14], [1:5 7]); Q=eye(6); Q(7:12,7:12)=n*eye(6); R=diag([rho rho rho rho rho/2 rho/2]); [Kb, S, E] = lqr(A, B, Q, R); Kb case 'c', %test case c is three free vehicles, disturbance rejection rho = 1/4; Q=n*eye(7); Q(8:14,8:14)=eye(7); R=diag([ rho rho rho rho rho/2 rho/2 rho/2]); [Kc, S, E] = lqr(A, B, Q, R); Kc case 'd', %test case d is three vehicles, tracking rho = 1/4; Q=eye(7); Q(8:14,8:14)=n*eye(7); R=diag([ rho rho rho rho rho/2 rho/2 rho/2]); [Kd, S, E] = lqr(A, B, Q, R); Kd end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 154 Dept of Aeronautics and Astronautics

I.1.4 Spin-up Approach 1 Code % Spinup dymanics % Calculated and written by Laila Elias, Leah Soffer, and Andre' Bosch % See Andre's Lab book page 14 with any questions clear all; close all; ramp=2; % 0 for constant k, 1 for ramp k, 2 for ramp higher than s.s. value switch ramp case 0 steps = 200; % number of timesteps total_time = 25; case 1 steps = 100; % number of timesteps total_time = 85; case 2 steps = 100; % number of timesteps total_time = 10; end dt = total_time/steps; % timestep in seconds (time for total maneuver/timesteps) time = dt:dt:steps*dt; mass = 20; % in kg I=1; %inertia thetadotdot = zeros(steps,1); % enough for time steps of .05 seconds thetadot = zeros(steps,1); theta_a = 0; % coordinate system fixed on vehicle a theta_b = zeros(steps,1); theta_bdot = zeros(steps,1); r = 1; % radius is one meter Frad = zeros(steps,1); % radial EM force Ftan = zeros(steps,1); % tangential EM force %F_rad = 3/(2*pi)*mu0*mua*mub/(2*r)^4 = m*omega^2*r %k = 3*mu0*mua*mub/(4*pi); mu0 = 4*pi*1e-7; omega = 2*pi/60; %in steady state %mu = sqrt(32*mass*(omega^2)*(r^5)/(3*mu0)*pi); %mu for each coil in steady state; d_coil= 0.83; %diameter of large coil in meters n = 100; %number of wraps in coil; k = 40*(pi^2)/3600*16; % constant terms in front, also takes into % account the mu's since we are saying they % are constant in this case. See lab book!k switch ramp

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 155 Dept of Aeronautics and Astronautics

case 0 k=k*ones(1,steps); case 1 root_k = sqrt(k); ramp_time = 69.7; dk = root_k/ramp_time*dt; ramp_k = [dk:dk:root_k root_k*ones(1,(steps-ramp_time/dt))]; k = ramp_k.*ramp_k; %theta = zeros(steps,1); case 2 root_k = sqrt(k); max_root_k=1.5*root_k; ramp_time_1 = 1; ramp_time_2 = 8; % max_ramp_k time should be 8 or less to make sense ramp_time_3 = 1; ramp_time_4 = total_time-(ramp_time_1+ramp_time_2+ramp_time_3); dk_1 = max_root_k/(ramp_time_1)*dt; dk_3 = -(max_root_k-root_k)/ramp_time_3*dt; ramp_k = [dk_1:dk_1:max_root_k max_root_k*ones(1,ramp_time_2/dt) max_root_k+dk_3:dk_3:root_k root_k*ones(1,ramp_time_4/dt)]; k = ramp_k.*ramp_k; %theta = zeros(steps,1); end % initial conditions NOTE Coriolis effect not in thetadotdot theta_b(1) = pi/2; thetadotdot(1) = (k(1)/mass/((2*r)^4)/r)*(sin(theta_b(1))*cos(theta_a)... +sin(theta_a)*cos(theta_b(1))); for count = 2:(steps); thetadot(count) = thetadot(count-1) + thetadotdot(count-1)*dt; %theta(count) = theta(count-1) + thetadotdot(count-1)/2*dt^2; %needs to add integral of thetadot term Frad(count) = -((thetadot(count))^2)*r*mass; theta_b(count) = acos(-Frad(count)*(2*r)^4/k(count)/2); if imag(theta_b(count)) ~=0 theta_b(count) = 0; end theta_bdot(count) = (theta_b(count) - theta_b(count-1))/dt; Ftan(count) = k(count)/((2*r)^4)*((sin(theta_b(count))*cos(theta_a))... +(sin(theta_a)*cos(theta_b(count)))); %r^5???? thetadotdot(count) = Ftan(count)/mass/r; end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 156 Dept of Aeronautics and Astronautics

real_k = k/3/(2*r)^3; %k defined in packet as mu0*muA*muB/(4*pi*d^3) delta = 0; chi = 0; %no rotation in plane %EM Torques on vehicle noted %T_EMxA = real_k'.*(sin(theta_a)*sin(theta_b)*sin(chi-delta)); %T_EMyA = real_k'.*(cos(theta_a)*sin(theta_b)*sin(delta)+2*sin(theta_a)*cos(theta_b)*sin(chi)); T_EMzA = -real_k'.*(cos(theta_a)*sin(theta_b)*cos(delta)+2*sin(theta_a)*cos(theta_b)*cos(chi)); %T_EMxB = real_k'.*(sin(theta_a)*sin(theta_b)*sin(delta-chi)); %T_EMyB = real_k'.*(2*cos(theta_a)*sin(theta_b(count))*sin(delta)+sin(theta_a)*cos(theta_b(count))*sin(chi)); T_EMzB = -real_k'.*(2*cos(theta_a)*sin(theta_b)*cos(delta)+sin(theta_a)*cos(theta_b)*cos(chi)); %Torque on reaction wheels theta_b_dotdot=[diff(diff(theta_b))]/dt^2; theta_b_dotdot = [theta_b_dotdot; theta_b_dotdot(end); theta_b_dotdot(end)]; T_RW_A = -(mass*r^2+I)*thetadotdot + T_EMzA; %Torque History Needed on RW A to Maintain Theta A at Zero T_RW_B = -(mass*r^2+I)*thetadotdot +I*theta_b_dotdot + T_EMzB; % Torque History Needed on RW B to Maintain the Theta B History Calculated Above %figure(5); set(gca,'fontsize',14); subplot(2,2,2); plot(time, theta_b); xlabel('Time [s]') ylabel('\theta_b [rad]') title('Angle of Spacecraft B from Radial Line') %figure(6); set(gca,'fontsize',14); subplot(2,2,3); plot(time, thetadotdot); xlabel('Time [s]') ylabel('\Theta_dd [rad/s^2]') title('Angular Acceleration of Array') %figure(7); set(gca,'fontsize',14); subplot(2,2,4); plot(time, thetadot); xlabel('Time [s]') ylabel('\Theta_d [rad/s]') title('Angular Rate of Array') mu = sqrt(k*4*pi/(3*mu0));

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 157 Dept of Aeronautics and Astronautics

i= mu/(n*pi*(d_coil/2)^2); %amps needed in coil for steady state?????????????????????????????? %figure(11); set(gca,'fontsize',14); subplot(2,2,1); plot(time,i); grid xlabel('Time [s]') ylabel('i [A]') title('Current in EM') figure; %figure(8); set(gca,'fontsize',14); subplot(2,1,1); plot(time,T_EMzA, time, T_EMzB); xlabel('Time [s]') ylabel('Torque [Nm]') title('Torque Needed From EM') legend('T_EMzA' , 'T_EMzB' ,0) %figure(9); set(gca,'fontsize',14); subplot(2,1,2); plot(time,T_RW_A, time, T_RW_B); xlabel('Time [s]') ylabel('Torque [Nm]') title('Torque Needed From Reaction Wheel A and B') legend('T_RWA', 'T_RWB', 0) if 0 figure(10); set(gca,'fontsize',14); plot(time,theta); xlabel('Time [s]') ylabel('') title('') end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 158 Dept of Aeronautics and Astronautics

I.1.5 Spin-up Approach 2 Code (has bugs) % Spinup dymanics % Calculated and written by Laila Elias, Leah Soffer, and Andre' Bosch % See Andre's Lab book page 14 with any questions clear all; close all; steps = 200; % number of timesteps total_time = 25; dt = total_time/steps; % timestep in seconds (time for total maneuver/timesteps) time = dt:dt:steps*dt; mass = 20; % in kg I=1; %inertia thetadotdot = zeros(steps,1); % enough for time steps of .05 seconds thetadot = zeros(steps,1); theta_a = 0; % coordinate system fixed on vehicle a theta_b = zeros(steps,1); theta_bdot = zeros(steps,1); theta_b_dotdot = zeros(steps,1); r = 1; % radius is one meter Frad = zeros(steps,1); % radial EM force Ftan = zeros(steps,1); % tangential EM force mu0 = 4*pi*1e-7; mu2 = zeros(steps,1); %mu squared (muA*muB) omega = 2*pi/60; %in steady state %mu = sqrt(32*mass*(omega^2)*(r^5)/(3*mu0)*pi); %mu for each coil in steady state; d_coil= 0.83; %diameter of large coil in meters n = 100; %number of wraps in coil; k = 3/(4*pi)*mu0/(2*r)^4; % initial conditions NOTE Coriolis effect not in thetadotdot theta_b(1) = pi/2; mu2(1) = 44.7*44.7; %steady state mu thetadotdot(1) = (k*mu2(1)/mass/r)*(sin(theta_b(1))*cos(theta_a)... +sin(theta_a)*cos(theta_b(1))); for count = 2:(steps); theta_b(count) = pi/4*cos(pi/total_time*time(count))+pi/4; thetadot(count) = thetadot(count-1) + thetadotdot(count-1)*dt;

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 159 Dept of Aeronautics and Astronautics

Frad(count) = -((thetadot(count))^2)*r*mass; mu2(count) = -Frad(count)/k/(2*cos(theta_a)*cos(theta_b(count))+sin(theta_b(count))*sin(theta_a)); Ftan(count) = k*mu2(count)*((sin(theta_b(count))*cos(theta_a))... +(sin(theta_a)*cos(theta_b(count)))); thetadotdot(count) = Ftan(count)/mass/r; end real_k = k/3*(2*r)*mu2; %k defined in packet as mu0*muA*muB/(4*pi*d^3) delta = 0; chi = 0; %no rotation in plane %EM Torques on vehicle noted %T_EMxA = real_k.*(sin(theta_a)*sin(theta_b)*sin(chi-delta)); %T_EMyA = real_k.*(cos(theta_a)*sin(theta_b)*sin(delta)+2*sin(theta_a)*cos(theta_b)*sin(chi)); T_EMzA = -real_k.*(cos(theta_a)*sin(theta_b)*cos(delta)+2*sin(theta_a)*cos(theta_b)*cos(chi)); %T_EMxB = real_k.*(sin(theta_a)*sin(theta_b)*sin(delta-chi)); %T_EMyB = real_k.*(2*cos(theta_a)*sin(theta_b(count))*sin(delta)+sin(theta_a)*cos(theta_b(count))*sin(chi)); T_EMzB = -real_k.*(2*cos(theta_a)*sin(theta_b)*cos(delta)+sin(theta_a)*cos(theta_b)*cos(chi)); %Torque on reaction wheels theta_bdot=diff(theta_b)/dt; theta_bdot= [theta_bdot(1); theta_bdot]; theta_b_dotdot=[diff(theta_bdot)]/dt; theta_b_dotdot = [theta_b_dotdot(3); theta_b_dotdot(3); theta_b_dotdot(3); theta_b_dotdot(3:end)]; T_RW_A = -(mass*r^2+I)*thetadotdot + T_EMzA; %Torque History Needed on RW A to Maintain Theta A at Zero T_RW_B = -(mass*r^2+I)*thetadotdot +I*theta_b_dotdot + T_EMzB; % Torque History Needed on RW B to Maintain the Theta B History Calculated Above %figure(5); set(gca,'fontsize',14); subplot(2,2,2); plot(time, theta_b); xlabel('Time [s]') ylabel('\theta_b [rad]') title('Angle of Spacecraft B from Radial Line') %figure(6); set(gca,'fontsize',14); subplot(2,2,3); plot(time, thetadotdot);

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 160 Dept of Aeronautics and Astronautics

xlabel('Time [s]') ylabel('\Theta_dd [rad/s^2]') title('Angular Acceleration of Array') %figure(7); set(gca,'fontsize',14); subplot(2,2,4); plot(time, thetadot); xlabel('Time [s]') ylabel('\Theta_d [rad/s]') title('Angular Rate of Array') mu = sqrt(k*4*pi/(3*mu0)); i= mu/(n*pi*(d_coil/2)^2); %amps needed in coil for steady state?????????????????????????????? %figure(11); set(gca,'fontsize',14); subplot(2,2,1); plot(time,i); grid xlabel('Time [s]') ylabel('i [A]') title('Current in EM') figure; %figure(8); set(gca,'fontsize',14); subplot(2,1,1); plot(time,T_EMzA, time, T_EMzB); xlabel('Time [s]') ylabel('Torque [Nm]') title('Torque Needed From EM') legend('T_EMzA' , 'T_EMzB' ,0) %figure(9); set(gca,'fontsize',14); subplot(2,1,2); plot(time,T_RW_A, time, T_RW_B); xlabel('Time [s]') ylabel('Torque [Nm]') title('Torque Needed From Reaction Wheel A and B') legend('T_RWA', 'T_RWB', 0) if 0 figure(10); set(gca,'fontsize',14); plot(time,theta); xlabel('Time [s]') ylabel('') title('') end

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 161 Dept of Aeronautics and Astronautics

theta_b_dot = diff(theta_b)/dt^2; figure; subplot(3,1,1); plot(time, theta_b); xlabel('Time [s]') ylabel('\theta_b [rad]') subplot(3,1,2); plot(time(1:end-1), theta_b_dot); xlabel('Time [s]') ylabel('\theta_d_b [rad/s]') subplot(3,1,3); plot(time, theta_b_dotdot); xlabel('Time [s]') ylabel('\theta_dd_b [rad/s^2]')

EMFFORCE OPS MANUAL Space Systems Product Development – Spring 2003

Massachusetts Institute of Technology 162 Dept of Aeronautics and Astronautics

References

Schweighart, Samuel A. Two Satellite Spin-up. Massachusetts Institute of Technology, 2002.