The SPHERES Guest Scientist Program Interface - SSL - MIT

The SPHERES Guest Scientist Program Interface Mark O. Hilstad, John P. Enright, and Arthur G. Richards MIT Space Systems Laboratory Document version 1.0 (2002-11-20)

Abstract To reduce mission cost and improve spacecraft performance, the National Aeronautics and Space Administration and the United States military are considering the use of distributed spacecraft architectures in several future missions. Precise relative control of separated spacecraft position and attitude is an enabling technology for many science and defense applications that require distributed measurements and autonomous docking. The SPHERES testbed provides a low-risk, representative dynamic environment for the interactive development and verification of formation flight, rendezvous, and docking control and autonomy algorithms. The SPHERES Guest Scientist Program provides remote investigators access to the testbed through the interface framework described in this document. The Guest Scientist Program algorithm and code development process involves several development and verification steps, culminating with SPHERES tests in micro-gravity aboard the ISS.

Table of Contents 1 2

SPHERES Overview........................................................................................................................3 Guest Scientist Program Overview ..................................................................................................5 2.1 Custom code development and test process.............................................................................5 2.1.1 GSP SPHERES simulation ..............................................................................................5 2.1.2 Laboratory........................................................................................................................6 2.1.3 International Space Station ..............................................................................................6 2.2 GSP package contents..............................................................................................................6 2.3 Delivery of custom code ..........................................................................................................7 2.3.1 Laboratory........................................................................................................................7 2.3.2 International Space Station ..............................................................................................7 2.4 Contacting the MIT SPHERES team .......................................................................................7 3 Sphere Physical Properties...............................................................................................................8 3.1 Body coordinate frame and external features...........................................................................8 3.2 Mass and inertia properties ......................................................................................................9 3.3 Actuators ................................................................................................................................10 3.3.1 Thrusters.........................................................................................................................10 3.3.2 Pressure system ..............................................................................................................12 3.4 Inertial sensors .......................................................................................................................13 3.4.1 Rate gyroscopes .............................................................................................................13 3.4.2 Accelerometers...............................................................................................................13 3.5 Global sensors ........................................................................................................................14 3.5.1 Global update process ....................................................................................................14 3.5.2 Ultrasound sensor geometry...........................................................................................15 4 Software Overview ........................................................................................................................17 4.1 Test organization....................................................................................................................17 4.2 Summary of user-configurable functions...............................................................................18 4.2.1 Priority, pre-emption, and data integrity ........................................................................19 4.3 State vector.............................................................................................................................20 4.4 Naming conventions ..............................................................................................................21 4.5 Individually customized software access ...............................................................................21 5 Estimation ......................................................................................................................................22 5.1 Measurement-triggered functions ..........................................................................................22 5.1.1 Inertial ............................................................................................................................23 5.1.2 Global.............................................................................................................................23 5.2 SPHERES standard estimator ................................................................................................24 5.3 Onboard direct-ranging beacons ............................................................................................25 2

6

Control ...........................................................................................................................................25 6.1 Control interrupt interface......................................................................................................25 6.2 Implementation guidelines .....................................................................................................26 6.3 Thruster actuation ..................................................................................................................27 6.3.1 Commanding actuation ..................................................................................................27 6.3.2 Calibration......................................................................................................................28 6.4 Standard control modules.......................................................................................................28 7 Event-driven task ...........................................................................................................................28 8 Communications ............................................................................................................................29 8.1 Overview................................................................................................................................29 8.1.1 Time-division multiplexing............................................................................................29 8.1.2 Loss of communications ................................................................................................29 8.2 Background Communications................................................................................................30 8.3 Foreground Communications.................................................................................................30 9 Initialization ...................................................................................................................................30 9.1 Program initialization.............................................................................................................30 9.2 Test initialization....................................................................................................................31 10 GSP SPHERES Simulation........................................................................................................31 11 Expansion Port ...........................................................................................................................32 12 Acknowledgements ....................................................................................................................32 13 References..................................................................................................................................32 14 Appendix A – GSP Package Contents .......................................................................................33 15 Appendix B – Document Change Log .......................................................................................33

1 SPHERES Overview The SPHERES testbed is a risk mitigation tool, providing a risk-tolerant medium for the development and maturation of formation flight and docking algorithms. The testbed is manifested for launch to the International Space Station (ISS) on service flight 12A.1, nominally scheduled for July 2003. The testbed will be operated by crewmembers in the micro-gravity environment aboard the ISS. Six degree-of-freedom (DOF) operations on the ISS are complemented by a 3 DOF low-friction air table facility in the Space Systems Laboratory (SSL) at MIT. The SPHERES separated spacecraft testbed provides investigators with a long-term, replenishable, and upgradeable platform for the validation of high-risk metrology, control, and autonomy technologies. These technologies are critical to the operation of distributed spacecraft and docking missions such as TechSat21, StarLight, Terrestrial Planet Finder, and Orbital Express. The SPHERES testbed consists of three free-flyer vehicles (commonly referred to as “spheres”), five ultrasonic beacons, and a laptop control station. The free-flyer spheres are self-contained, with onboard power, propulsion, communications, sensor, and computer subsystems. They operate semiautonomously, requiring human interaction primarily for replenishment of consumables and to command the beginning of each test. An external view of the sphere design, showing thrusters, ultrasonic sensors, propellant tank, and pressure system regulator knob, is given in Figure 1.

3

Figure 1. A sphere. This document details the Guest Scientist Program interfaces to the SPHERES flight software, and provides guest scientists with a framework in which to implement custom algorithms. The elements of the sphere hardware and software are organized by subsystems representative of those on real spacecraft. The avionics, communications, propulsion, control, and state estimation subsystems are directly relevant to the ability of the spheres to perform coordinated maneuvers. The following list summarizes key features of the testbed: • •

• •

•

•

The flight software is written in C, and runs on a Texas Instruments C6701 DSP at 167 MHz. Sensor data are sampled and digitized by an FPGA at 12-bit resolution. The communications subsystem consists of two independent radio frequency channels. The sphere-to-sphere channel is used for communication between the spheres, and the sphere-tolaptop channel is used to send command and telemetry data between the spheres and the laptop control station. Actuation is provided by twelve cold-gas thrusters fed by a tank containing liquid CO2 propellant. Thruster forces are fixed, but pulse modulation to a time resolution of one millisecond can be used to provide effective variable impulse levels. The position and attitude determination system has both inertial and external sensors. Gyroscopes and accelerometers are available for rapid updates to the state estimate over short time periods, and ultrasonic time of flight range measurements from wall-mounted beacons to the sphere surfaces are used to update the state estimate with respect to the laboratory reference frame. A periodic control interrupt can be used for implementation of fixed or variable frequency control laws. A suggested approach to the implementation of modular algorithms for use in the control interrupt is provided, and several useful modules are supplied with the GSP package. An event-driven background task is available to complement and augment traditional estimation and control processes. The combination of the task process with the estimation and control processes allows guest scientists significant freedom in algorithm design.

The SPHERES testbed is a shared facility and guest scientists working at distributed locations hold a very diverse set of interests. To satisfy the needs of these researchers, the MIT SPHERES team has developed a flexible interface to the software and hardware. Guest scientists are encouraged to contact the MIT SPHERES team if the interface lacks any capabilities necessary for their

4

investigations. If we are unable to suggest solutions applicable to the current interface, additional features may be accommodated in subsequent releases of the GSP interface package.

2 Guest Scientist Program Overview 2.1 Custom code development and test process The custom algorithm development and test process consists of three stages, utilizing three different development environments: the GSP SPHERES simulation, the 3-DOF environment of the laboratory, and the 6-DOF environment of the International Space Station. These three stages exhibit various levels of accessibility and fidelity, as depicted in Figure 2. GSP simulation (0-g, 1-g)


SPHERES laboratory (1-g)

  




  

SPHERES ISS (0-g)

Figure 2. Accessibility vs. fidelity of GSP development and test stages. The high-level process by which guest scientists develop and code algorithms is outlined in Figure 3. Guest scientists independently develop custom algorithms, implement and test them using the MITsupplied GSP simulation. The simulation provides the guest scientist with the means to compile and debug custom C source code, and to iterate the algorithm design as necessary to achieve desired results. Once acceptable performance has been demonstrated using the simulation, the custom source code is delivered to the MIT SPHERES team for verification on the flight hardware, before the algorithms are sent to the ISS. The software interfaces to the simulation and to the flight hardware are identical, so no additional interfacing work is required between each development step. The development process is iterative, and feedback regarding algorithm performance is available to guest scientists at each stage.       Independent algorithm and source code development

GSP simulation

GSP interface package



    

Deliver to SPHERES

Laboratory testbed

International Space Station

Figure 3. Guest Scientist code development process

2.1.1 GSP SPHERES simulation The guest scientist begins the custom software development process by writing custom source code that adheres to the software interface described in this document. This source code is then compiled

5

and tested with the GSP SPHERES simulation. This simulation is provided to the guest scientist as part of the GSP package. Compiling the GSP simulation verifies syntactic correctness of the guest scientist’s code, and the application itself emulates basic operations of the testbed 0-g or 1-g dynamics. Once the code has been compiled and debugged by the guest scientist, it can be sent immediately to the SPHERES team at MIT for testing on flight hardware in the laboratory. The GSP simulation requires an x86-compatible computer running the Microsoft Windows 2000 operating system. In addition, Microsoft Visual C++ is required to compile code for the simulation, and The Mathworks’ MATLAB is required to run the data reduction scripts included with the GSP package.

2.1.2 Laboratory The laboratory is used to verify the expected operation of developed algorithms on the flight hardware. The hardware used in the laboratory is identical to the ISS flight hardware, and realistic imperfections, uncertainties, unmodeled effects, and hardware limitations are present; however, in the laboratory, the presence of gravity restricts the movements of the spheres. The laboratory testbed operates on a 1.2 m × 1.2 m glass surface, mounted horizontally on a lab bench. The spheres are mounted to air carriages, which float on the glass surface by means of compressed air. This arrangement allows planar translation and single-axis rotation. The ultrasound beacons used for range measurement are arranged to provide good coverage over the 2-D test surface. Two types of disturbances degrade laboratory performance. First, imperfections and contaminants on the air table surface create uneven friction forces. Second, slight tilting of the tabletop results in a constant bias force. Laboratory performance data returned to guest scientists include downloaded telemetry. It is also possible to arrange the laboratory testbed in a station configuration. For these tests, one or more spheres are suspended in the test volume, and the beacons are arranged to provide threedimensional coverage. This configuration is similar to that used in orbit aboard the ISS. Although motion is limited, better sensor visibility and representative body-blockage effects make this technique useful for evaluating estimation algorithms in 3-D.

2.1.3 International Space Station The micro-gravity environment of the ISS allows for maneuvers in 6 DOF. The useable test space will most likely be a 1.5 × 1.5 × 2 m (5 × 5 × 6ft) volume. The most likely operating location for the testbed aboard the ISS is in the U.S. Node (the Unity module), where airflow rates are approximately 3 cm/s (0.1 ft/s). Additional environmental data will be included in this document when the operating environment and disturbances are more fully characterized. Accessibility to the testbed by the MIT SPHERES team and guest scientists is limited to occasional software updates. Telemetry and video footage will be available for evaluating algorithm performance.

2.2 GSP package contents The complete GSP development package may be downloaded from the SPHERES GSP homepage at http://ssl.mit.edu/spheres/gsp/. The package consists of the following elements: • • • • •

The GSP interface document (this document) Pre-compiled SPHERES C libraries Header files describing the library interfaces Templates for user-modifiable source code files (gsp.c and gsp.h) Example source code

6

• • •

Template for HTML test descriptions Simulation environment executable programs A MATLAB data reduction script

A listing of the files included with the GSP package may be found in Appendix A; the complete package will be made available with release 1.5 of the GSP interface document.

2.3 Delivery of custom code 2.3.1 Laboratory Delivery to MIT of custom code for test in the laboratory must consist of a zip archive containing the following items: •

•

Custom source code files for each sphere o gsp.c o gsp.h o Any additional source code included with #include in any of the versions of gsp.c or gsp.h. A description of the test, test parameters, and expected behavior

2.3.2 International Space Station Delivery to MIT of custom code destined for the ISS must consist of a zip archive containing the following items: •

•

Custom source code files for each sphere o gsp.c o gsp.h o Any additional source code included with #include in any of the versions of gsp.c or gsp.h. An HTML description of the test, test parameters, and expected behavior, for use by crewmembers while conducting tests. A template for the HTML description will be available in the GSP package.

Delivery of these items to MIT must be made a minimum of six working days before the scheduled uplink to the ISS. Additional details regarding final delivery will be provided later.

2.4 Contacting the MIT SPHERES team Individuals interested in participating in the SPHERES program should contact the MIT SPHERES team at [email protected]. This address may also be used for general inquiries. Questions sent to this address or to individual SPHERES team members may be used or adapted for a Frequently Asked Questions (FAQ) list to be posted with answers on the SPHERES GSP home page. Each guest scientist will be assigned a point of contact on the SPHERES team. Once custom source code has been verified using the GSP simulation, the guest scientist should deliver the elements specified in Section 2.3 to [email protected]. Table 1 lists the members of the SPHERES team and their primary responsibilities.

7

Table 1. The SPHERES team

Name Prof. David Miller Dr. Edmund Kong Dr. John Enright Dustin Berkovitz Mark Hilstad Simon Nolet Alvar Saenz-Otero Stephanie Chen (PSI) Steve Sell (PSI)

Primary responsibilities Principle Investigator Lead Scientist, metrology Software Propulsion system GSP, simulation, metrology Propulsion system Hardware, operations Procedures, operations Flight integration

A mailing list for official announcements enables efficient dissemination of important SPHERESrelated information. Please contact the SPHERES team to be added to this list.

3 Sphere Physical Properties 3.1 Body coordinate frame and external features The sphere body coordinate frame is defined as follows, and is shown in Figure 4. Figure 5 shows a perspective view of the sphere hardware design. • • • •

The origin is located at the geometric center +x points in the direction of the onboard direct ranging beacon +z points in the direction of the pressure system regulator knob +y completes a right-hand system Ultrasound sensor

Expansion port

Switch panel

-X

Pressure regulator knob

Pressure gage

-Z

+Z

-Y

+Y

Battery door

+X

CO2 propellant tank

Thruster Onboard beacon

Figure 4. An unwrapped view of a sphere, showing body frame coordinate system and physical features.

8

-X

Thruster

Ultrasonic receivers CO2 tank

Adjustable regulator

Pressure gauge

+Z

-Y

Figure 5. A rendered CAD model of the sphere hardware. The CAD model is labeled with the body coordinate frame and several physical features. The switch panel is not pictured. Several features of the sphere hardware that are visible in Figure 4 and Figure 5 such as thrusters, sensors, and the pressure system, are discussed in detail later in this section.

3.2 Mass and inertia properties Wet and dry mass and inertia properties were obtained using a CAD model, and the masses of individual parts and of the entire assembly were verified empirically. Wet mass values apply to a sphere with a full propellant tank, and dry mass values refer to a sphere with an empty tank. The mass and inertia property numbers given in Table 2 through Table 7 are accurate to 1%.[3] Table 2. Sphere mass (kg).

Wet 4.38

Dry 4.21

Table 3. Center of mass with respect to the body coordinate frame (m).

x y z

Wet 0.00048 -0.00119 0.00108

Dry 0.00049 -0.00124 0.00398

Table 4. Inertia tensor at body frame center, with respect to body coordinate frame (kg m2).

Ixx Iyy Izz Ixy Ixz Iyz

Wet 2.29×10-02 2.42×10-02 2.14×10-02 9.65×10-05 -2.93×10-04 -3.11×10-05

9

Dry 2.18×10-02 2.31×10-02 2.13×10-02 9.64×10-05 -2.87×10-04 -4.61×10-05

Table 5. Inertia tensor at center of mass, with respect to body coordinate frame (kg m2).

Ixx Iyy Izz Ixy Ixz Iyz

Wet 2.30×10-02 2.42×10-02 2.14×10-02 9.90×10-05 -2.95×10-04 -2.54×10-05

Dry 2.19×10-02 2.31×10-02 2.13×10-02 9.90×10-05 -2.95×10-04 -2.54×10-05

Table 6. Principal axes (kg m2).

Ixx Iyy Izz

Wet 2.17×10-02 2.32×10-02 2.47×10-02

Dry 2.14×10-02 2.23×10-02 2.36×10-02

Table 7. Radii of gyration with respect to principal axes (m).

r1 r2 r3

Wet 7.00×10-02 7.24×10-02 7.47×10-02

Dry 7.09×10-02 7.23×10-02 7.44×10-02

3.3 Actuators Each sphere relies on a set of twelve on-off thrusters for management of both position and attitude. The thrusters are fed with gaseous CO2 propellant, stepped down from a high tank storage pressure through a manually adjustable single-stage regulator.

3.3.1 Thrusters The sphere thruster geometry enables the production of pure body-axis force or torque using only two thrusters, assuming uniform mass and inertia properties. The twelve thrusters are arranged in six back-to-back pairs, allowing for full 6 DOF actuation. A diagram of the sphere thruster configuration is shown in Figure 6.

10

-X

3

1 -Z

9

0 5

-Y

11

10

+Z

7

+Y

4

6

+X

2

Thruster, indicating exhaust direction

8

Figure 6. Schematic view of the sphere thruster geometry. The thruster force and torque direction properties are listed in Table 8. For a given thruster number, these data indicate the directions of the force and torque that will be produced by firing that thruster. For example, firing thruster number seven produces negative x-axis force and positive y-axis torque. Table 8. Thruster geometry, in the body coordinate frame.

Thr #

Thruster position [cm] x y z -5.16 0.0 9.65 -5.16 0.0 -9.65 9.65 -5.16 0.0 -9.65 -5.16 0.0 0.0 9.65 -5.16 0.0 -9.65 -5.16 5.16 0.0 9.65 5.16 0.0 -9.65 9.65 5.16 0.0 -9.65 5.16 0.0 0.0 9.65 5.16 0.0 -9.65 5.16

0 1 2 3 4 5 6 7 8 9 10 11

Resultant force direction x y z 1 0 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 1 -1 0 0 -1 0 0 0 -1 0 0 -1 0 0 0 -1 0 0 -1

Resultant torque direction x y z 0 1 0 0 -1 0 0 0 1 0 0 -1 1 0 0 -1 0 0 0 -1 0 0 1 0 0 0 -1 0 0 1 -1 0 0 1 0 0

The force and torque directions in Table 8 can be used to determine the combination of thrusters required to produce force along or torque about each body axis. The production of force or torque through a non-body axis can be achieved through a vector sum of the body-axis components. Table 9 lists the thruster combinations that produce pure body-axis actuation, under the assumption that all thrusters produce equal magnitude force and that all moment arms are equal. Table 9. Thruster combinations to produce pure body-axis actuation.

Thr # 1 2 3

+x × ×

Body-axis force -x +y -y +z

-z

×

11

+x

Body-axis torque -x +y -y +z × × ×

-z

4 5 6 7 8 9 10 11 12

× × ×

× × × ×

×

× × ×

× ×

×

×

× ×

×

At the nominal feed pressure of 35 psig, each thruster delivers approximately 0.1 N of force. Variability from this value is small, but the force magnitude of each thruster is slightly offset from the nominal value. These deviations will be measured in the laboratory, and thruster-specific measured forces are available through software (see Section 6.2). Temporal deviations due to the number or combination of thrusters open at a particular time are more difficult to characterize, and the effects of these variations are currently treated as disturbances. The on-off thrusters used on the spheres exhibit nonlinear, discontinuous, bounded behavior. Each thruster consists of a solenoid valve and a nozzle. When a thruster is commanded on, a voltage spikeand-hold circuit activates and holds open the solenoid valve. The thruster output force increases rapidly (0

Units Description counts Raw accelerometer counts from sensor samples made since the last call to this function, passed as an array of pointers to buffered data. The counts are accessed with accel[index][type], where 0 ≤ index < number, and type is either PADS_RAW_ACCELX, PADS_RAW_ACCELY, or PADS_RAW_ACCELZ. Higher values of index correspond to newer measurements. counts Raw gyroscope counts from sensor samples made since the last call to this function, passed as an array of pointers to buffered data. The counts are accessed with gyro[index][type], where 0 ≤ index < number, and type is either PADS_RAW_GYROX, PADS_RAW_GYROY, or PADS_RAW_GYROZ. Higher values of index correspond to newer measurements. -Number of measurements recorded from each sensor since the last call to this function. Quantities smaller than number are valid indices into accel and gyro, and can be used to retrieve buffered inertial measurements.

The rate at which inertial sensors are sampled and inertial data are processed can be set with the following function. uint padsInertialPeriodSet(sample,multiplier) Description:

Changes the periods of the inertial sensor sampling and inertial data processing routines. Setting sample to zero disables both routines.

Returns:

A non-zero return value indicates an invalid period.

Argument sample multiplier

Type uint uint

Values Units Description ms Desired period for inertial sensor sampling. ≥0 1 ≤ x ≤ 100 ms Number of sample periods per call of gspPadsInertial(…).

The maximum allowed inertial sensor sample frequency is 1 kHz, corresponding to a 1 ms period. Calibration utilities that provide sphere-specific calibration and scaling factors will be provided with a future release.

5.1.2 Global The function gspPadsGlobal(…) is called at 20 millisecond intervals during global updates, once for each beacon. The contents of this function may be written as desired by the guest scientist.

23

gspPadsGlobal(beacon,measurements,reference) Description: Called automatically whenever new global metrology (range) data are available. This function is prototyped in gsp.h, and the function contents in gsp.c may be written as desired by the guest scientist. Argument beacon measurements

Type uint float*

Values 0≤x≤7 ≥0

reference

uint

0 ≤ x ≤ 255

Units Description -- Beacon from which ranges were measured. cm A 6 × 4 array containing range measurements. The first index to the array specifies the face (0 ≤ x < 6) and the second index specifies the receiver (0 ≤ x < 4). -- Global update reference number. Increments with each update, and wraps back to zero after reaching 255.

Global updates may be configured as periodic or explicitly requested on demand. The function padsGlobalPeriodSet(…) is used to configure periodic global updates. Note that thrusters are disabled during global updates, in order to avoid ultrasonic interference. It is good practice to designate only one sphere to request global updates, as multiple spheres requesting global updates may result in unexpected behavior and excessive thruster quiet time. padsGlobalPeriodSet(period) Description: Specifies the period at which this sphere will request global updates. Setting the period to zero disables periodic updates. Argument Type Values Units Description period uint ms Global update period. ≥0

Instead of performing periodic global updates automatically, a GS routine may explicitly request updates at particular times. A call to the function padsGlobalRequest(…) results in an infrared flash that initiates a single instance of the global update process. padsGlobalRequest(delay) Description: Requests a global update after waiting delay milliseconds. If this function is called a second time before the delay time has elapsed after the first call, the delay time specified in the second call will be used. If a global update occurs before the delay time has elapsed (as requested by another sphere), the request is voided. Argument Type Values Units Description delay uint ms Delay time before requesting a global update. ≥0

Low-level functions ensure that only one global update occurs at a time, in order to prevent corruption of range data. Therefore, periodic or on-demand updates will be cancelled if they are scheduled to begin during an update already in process. Global updates can be performed at a maximum of 9 Hz when using only the five external beacons, and 5.8 Hz when using all 8 beacons. By default, the global update is performed at 2 Hz, to minimize thruster quiet time.

5.2 SPHERES standard estimator The SPHERES standard estimator determines the position, velocity, attitude (quaternion), and angular rate of the sphere. The standard estimator may not be disabled, but the guest scientist may choose to use the results from a custom estimator instead. The state vector used by the standard estimator follows the state element convention described in Section 4.3. A local copy of the standard estimator’s state values is made by a call to padsStateGet(…). padsStateGet(state) Description: Copies the current 13-element state estimate as determined by the standard estimator, to the location specified by state.

24

Argument state

Type float*

Values Units Description --- An array to which the default state elements, as determined by the standard estimator, will be written.

5.3 Onboard direct-ranging beacons The onboard beacons are disabled by default, in order to minimize thruster quiet time. The onboard beacons may be enabled or disabled at any time using the function padsBeaconNumberSet(…). Enabling the beacon on any one sphere increases the thruster quiet time on all spheres to 20 ms longer than the wait time of that beacon, but does not automatically enable the other two beacons. Note that it may take a second or more for the other spheres to adjust their thruster quiet times to accommodate the additional beacon. padsBeaconNumberSet(number) Description: Turns the onboard beacon on or off, and sets the beacon delay time. Turning on an onboard beacon increases the thruster quiet time during global updates for all spheres. Argument number

Type Values Units Description uint PADS_BEACON_OFF, -- The beacon number of this beacon. The beacon number determines the delay time after the infrared flash before the beacon transmits 5, 6, 7 ultrasound. The delay time is 10+20*number, in milliseconds. The delay is used by each receiving sphere to identify the beacon, so each sphere should have a different value for number. Setting number to PADS_BEACON_OFF disables the beacon (the default condition).

6 Control Two separate processes can be used for implementing control algorithms. A periodic interrupt process is available for performing repetitive, time-dependent operations such as following a curved trajectory and setting thruster on-times, and an event-driven background task is available for performing longterm, low-priority computation such as future trajectory planning. Both of these processes have fixed arguments, but guest scientists are free to use global memory to store or exchange additional data between any of the GSP processes. The task provides great freedom in algorithm design, while the control interrupt provides a simple structured interface. The task is described in Section 7. For researchers primarily concerned with estimation, autonomy, or limited aspects of the control problem, the MIT SPHERES team provides a standard set of modular control functions that can be called in the control interrupt, to perform simple maneuvers. Development of these utilities is ongoing, and additional modules will be made available on the SPHERES GSP home page as they are developed.

6.1 Control interrupt interface The control interrupt is typically used to implement a fast control law, with the result of setting thruster on and off times for the next control period. The number and elapsed time of the current test and maneuver are passed as arguments to the control interrupt. The commands defining each test and its underlying maneuvers are specified by the guest scientist in the function gspControl(…). gspControl(testNumber,testTime,maneuverNumber,maneuverTime) Description: Called by the control interrupt at the period specified by ctrlPeriodSet(…). Argument

Type

Values

Units Description

25

testNumber testTime maneuverNumber maneuverTime

uint uint uint uint

≥0 ≥0 ≥0 ≥0

ms ms ms ms

The current test number. The elapsed time of the current test. The current maneuver number. The elapsed time of the current maneuver.

The period of the control interrupt may be set and queried using the following functions. uint ctrlPeriodSet(period) Description: Changes the period of the periodic control interrupt. Setting the period to zero disables the control interrupt. Returns: A non-zero return value indicates an invalid period. Argument period

Type Values Units Description uint ms Desired control interrupt period. ≥0

The contents of the function gspControl(…) may be chosen freely by the guest scientist, but the MIT SPHERES team has developed a set of interface guidelines that facilitate rapid test development and the simple and effective reuse of existing code. Following these guidelines assists in operational organization, and allows the guest scientist to use a supplied set of modular algorithm blocks that satisfy common algorithmic needs. These interface guidelines are described in the following sections.

6.2 Implementation guidelines The guidelines provided in this section are suggestions that are intended to assist guest scientists in the implementation of algorithms. These guidelines are motivated by algorithmic, operational, and simplicity considerations based on the experiences of the SPHERES team, but they are not development rules. Guest scientists are free to design the contents of gspControl(…) as desired. The algorithmic processes that occur within a particular maneuver can often be broken down into the following categories: •

Command:

•

Control law:

•

Mixer:

•

Termination:

Generates a reference quantity, for example the current desired state on a particular trajectory. Application of a control law to the state and reference quantities, leading to desired force and torque or ∆V. Assignment of thruster on-times based on force and torque or ∆V, thruster geometry, and other considerations. Compare current conditions to some set of maneuver termination conditions, and signal maneuver completion when the termination conditions are met.

Some of these maneuver elements may change during a test, and others may not. Implementing each element in a separate algorithm module simplifies the development process, and enhances the ability to make incremental changes when problems arise. For example, using a well-tested mixer module during the debugging of a new control law module reduces the possibility that an algorithmic error in the mixer module is to blame for any unexpected behavior. A suggestion for the maneuver organization is shown in Figure 13. When a test begins, the maneuver number is set to zero by the underlying code. Each time gspControl(…) is called, the command, control law, mixer, and terminator corresponding to maneuver 0 are called. When the terminator signals that the maneuver is complete, the maneuver number increments and the next call to gspControl(…) calls the functions corresponding to maneuver 1. This process of terminating and incrementing the maneuver number continues until the test is complete.

26

Maneuver 0

Maneuver 1

Maneuver 2

Command

Command

Command

Control Law

Control Law

Control Law

Mixer

Mixer

Mixer

Terminator

Terminator

Terminator

Begin test

End test

Figure 13. Suggested maneuver process diagram.

6.3 Thruster actuation 6.3.1 Commanding actuation Typically, the control law generates continuous force, torque, or ∆V requests. These requests must be converted into individual thruster requests (forces, for example) based on the thruster geometry. Because the thrusters are on/off actuators, a pulse modulation algorithm must be employed to convert the forces into discrete on and off times for each thruster. Functions fulfilling this purpose are referred to as “mixers.” The function ctrlMixSimple(…) is an example of a typical mixer utility. Future releases will include additional mixers specialized to various control configurations. ctrlMixSimple(force,torque) Description: Converts continuous forces and torques in the body frame to discrete thruster on and off times. Applies knowledge of the thruster geometry to determine thruster forces, then applies pulse modulation rules to determine the time at which each thruster should be turned on and off over the next control period. Finally, the on and off times are written to the thrusters. Argument force

Type float*

Values ≥0

torque

float*

≥0

Units Description N 3-place array specifying body frame x, y, z forces to apply over the next control period. N m 3-place array specifying body frame x, y, z torques to apply over the next control period.

For lower-level access, thruster on and off time commands are set using propThrustersSet(…). The times at which the thrusters are to be turned on, and the times at which the thrusters are to be turned off, are passed to the function propThrustersSet(…) as two, twelve-element arrays of integers. Time is specified in millisecond values. propThrustersSet(turnOn,turnOff) Description: Writes the thruster on and off times for the next control period. The turnOn and turnOff values are referenced to the beginning of each control interrupt; i.e. setting turnOn[7] equal to 4 and turnOff[7] equal to 59 specifies to turn on thruster 7 beginning 4 milliseconds into the control period, and to turn it off 59 milliseconds into the control period, resulting in a total on-time of 55 milliseconds. Each call to this function overwrites any remaining on-time instructions set by the previous call. Argument turnOn turnOff

Type uint* uint*

Values ≥0 ≥0

Units Description ms 12-place array specifying when to turn on each thruster. ms 12-place array specifying when to turn off each thruster.

27

6.3.2 Calibration Steady-state deviation in the force magnitude produced by each thruster from the average value has been measured in the laboratory, and calibration data are recorded in the flight software. The presence of the calibration values allows the guest scientist to use an idealized model for thruster forces, and the same idealized model for each sphere. The calibration data may be applied to the on-time values determined by the control algorithm before the pulse modulation algorithm is applied. The function propForcesGet(…) may be used to make a local copy of the laboratory-measured steady-state force from each thruster at the nominal operating pressure of 35 psig. propForcesGet(forces) Description: Retrieves the steady-state thruster force values as measured in the laboratory at a thruster feed pressure of 35 psig. Argument forces

Type float*

Values ≥0

Units Description N 12-place array of steady-state forces.

Future revisions will contain additional functions for interaction with the propulsion system.

6.4 Standard control modules For guest scientists who are not concerned in writing control algorithms, the SPHERES team provides standard maneuver modules to perform simple operations. This section describes the most simple of those controllers. ctrlPositionHold(state,position,forces) Description: Calculates forces to maintain sphere stationary at commanded position. Argument state position forces

Type float* float* float*

Values

Units Description Pointer to 13-element state vector obeying the convention in Section 4.3 m Pointer to 3-element array containing desired position in global frame. N Pointer to 3-element array to hold force outputs.

ctrlAttitudeAlign(state,torques) Description: Calculates torques to maintain sphere body axes aligned with global frame. Argument state torques

Type float* float*

Values

Units Description Pointer to 13-element state vector obeying the convention in Section 4.3 N m Pointer to 3-element array to hold torque outputs.

Future revisions of this document will describe additional such functions as they are released.

7 Event-driven task The purpose of the event-driven task is to provide guest scientists with a means to implement algorithms that do not fit conveniently into the framework of the control and measurement-based estimation interrupt processes. In addition, the task provides a means for interpreting received communications data, and performing long-term, non-real-time, or low-priority computation. The contents of the task are defined by the guest scientist in the function gspTask(…). gspTask(…TBD…) Description: Called when one or more user-configurable events have occurred. Performs background computation tasks as desired by the guest scientist.

28

Argument TBD

Type TBD

Values TBD

Units Description TBD TBD

Future revisions will describe the task in detail.

8 Communications 8.1 Overview Two separate channels are available for command and telemetry communications. The sphere-tosphere (STS) channel is used to pass information between two or more spheres, and the sphere-tolaptop (STL) channel is used for the transfer of commands from and telemetry to the laptop control station. Relevant properties of the STS and STL communications channels are given in Table 20. Table 20. Communications system properties

Property Radio frequency (MHz) Packet data size (bytes) Bandwidth (packets/s)

sphere-to-sphere (STS) 916.5 32 70

sphere-to-laptop (STL) 868.35 32 70

It is important to ensure that the available communications capacity on each channel is not exceeded since data may be lost. The rate at which each buffer is emptied depends on the data rate of the channel that it serves. Two types of communication occur on each channel: background and foreground. Background refers to the automatic, periodic transmission of standard information, such as state and basic housekeeping data. Foreground refers to data explicitly sent by the guest scientist. Later sections describe each of these in detail.

8.1.1 Time-division multiplexing The spheres and laptop (referred to in the context of communications as “stations”) use a time-division multiple access (TDMA) protocol to enable transmission of information by all stations. During the software initialization process, a transmit window and frame length must be specified for each channel and station. The transmit window is the portion of the TDMA frame during which that particular station may transmit. The transmit windows on a given channel for different stations must not overlap, and the transmit windows for the two channels on a particular sphere should not overlap. For optimal performance, the window length should be approximately equal to the time required for an integral number of packet cycles (serial transmit followed by RF transmit). The frame length may be chosen arbitrarily by the guest scientist, but it should be noted that a frame duration of no more than half the control period is necessary to guarantee that confirmation of packet delivery can be received within a given control period.

8.1.2 Loss of communications The laptop acts as a master time reference, and periodically broadcasts frame synchronization packets on the STL channel. Each time a sphere receives a synchronization packet, it resets a frame counter. Failure to receive several of these synchronization packets in a row is interpreted as loss of communications due to departure from the test volume, and results in safing. The sphere response to a safing event is to cease all transmissions and disable the thrusters. This behavior is required to address ISS safety requirements.

29

8.2 Background Communications Several types of important data are regularly exchanged between the spheres and the laptop in processes transparent to the guest scientist; these processes are termed background communications. State data sent through background communications can then be retrieved in other spheres by calling the comBackgroundStateRead(…) function. long comBackgroundStateRead(sphere,data) Description: Retrieves background communications telemetry from a specified sphere. Returns: The timestamp (from sending sphere) of the retrieved telemetry, in units of milliseconds. Argument sphere data

Type uint float*

Values SPH1, SPH2, SPH3

Units Description -- The ID of the sphere from which telemetry is desired. -- The array in which to write the requested data.

For example, sphere 1 may copy the most recently communicated values of the sphere 2 state into the array sph2State with comBackgroundStateRead(SPH2,sph2State).

8.3 Foreground Communications Arbitrary data can be sent between spheres using a standard set of telemetry packing and queuing functions, though it is up to the guest scientist to provide code to interpret the data when they are received. Explicit transmission of data is termed foreground communication. A set of packing functions is supplied to support conversion of various data types into an acceptable telemetry format. Foreground communications will be detailed in a future release.

9 Initialization 9.1 Program initialization During the initialization process after a program upload or reset, the function gspBootInit(…) is called by the flight software. This function must be used to set certain important parameters, as well any custom initialization. gspBootInit() Description: Sets basic properties of the sphere, and initializes custom variables.

The contents of this function determine the sphere identity number and other important properties of the sphere; this is therefore the only GSP-related function that must contain certain function calls. Specifically, a call to sysIdentitySet(…) and two calls to comTdmInit(…) (one for each communications channel) must be the first actions taken in this function. After these three function calls, gspBootInit() may contain any custom initialization. sysIdentitySet(sphere) Description: Sets the identity of this sphere. All spheres must have different arguments to this function. This must be the first function called in gspBootInit(…). Argument sphere

Type uint

Values Units Description -- The identity of this sphere. SPH1, SPH2, SPH3

30

comTdmInit(channel,on,off,frameLength) Description:

Initializes the communications time division multiplexing. All spheres must have identical frameLength, and the specified window for each sphere must not overlap those of the other spheres. To improve performance, the STS and STL windows for a given sphere should not overlap.

Argument channel on off frameLength

Type Values Units Description uint COM_STS, COM_STL -- Specifies which spheres are to be used in this test. uint 1 ≤ x ≤ frameLength ms Starting millisecond for this sphere’s transmit window. uint 1 ≤ x ≤ frameLength ms Ending millisecond for this sphere’s transmit window. uint ms Length of the TDM frame ≥ 15

In addition, the function padsGlobalPeriodSet(…) may be called by one sphere, in order to designate a PADS master. If multiple spheres call this function, each one will periodically request PADS updates, resulting in unexpected behavior. This function is described on page 24.

9.2 Test initialization The function gspTestInit(…) is called whenever a new test is commanded through the laptop control station. Typical uses of this function will be described in a future release. gspTestInit(test) Description: Called to initialize test-specific quantities. Argument test

Type uint

Values Units Description -- The current test number. ≥0

10 GSP SPHERES Simulation The GSP SPHERES simulation is designed to maximize the effectiveness of interactions between the Guest Scientist and the MIT SPHERES team. It is particularly valuable during early stages of algorithm development and implementation. Algorithms may be implemented in the GSP simulation environment to verify correct compilation, interaction with the existing spheres on-board code, and desired behavior. The simulation writes to a text file the sphere telemetry received during a simulation period, as well as some additional debug information. The included Matlab function spheres_reduce.m may be used to reduce and plot the time history data. The simulation will support single sphere operations upon initial release, and will later support three-sphere operations. Both sphere-to-sphere (STS) and sphere-to-laptop (STL) communication channels are supported. The GSP simulation consists of major sections of SPHERES flight code, and additional code that simulates dynamics, communications, and other environmental interaction. A screen shot of the GSP SPHERES simulation is shown in Figure 14. The simulation will be described and released with a future release of this document.

31

Figure 14. The GSP simulation graphical user interface. The simulation server, control panel, and three sphere processes are visible, along with shortcuts to these programs on the desktop.

11 Expansion Port Each sphere is equipped with an expansion port that may be used to interface with additional hardware. The expansion port is not supported at this time, but will be available for the addition of custom hardware if a SPHERES reflight occurs.

12 Acknowledgements The MIT SPHERES team would like to thank everyone who supplied feedback on the GSP interface design and on this document. In particular, Russell Carpenter of NASA GSFC and Arthur Richards of MIT provided valuable critiques of the interface at many stages in its development.

13 References Data and text from several sources were used to prepare this document. Information came from the following sources: 1. BEI Systron Donner Inertial Division, “BEI GYROCHIP II micromachined angular rate sensor,” http://www.systron.com/pdfs/GyroIIDS.pdf, 21 March 2002. 2. Chen, Allen, “Propulsion system characterization for the SPHERES formation flight and docking testbed,” Master's thesis, Massachusetts Institute of Technology, Department of Aeronautics and Astronautics, June 2002. 3. Guerra, Edison, Payload Systems, Inc., personal contact. 4. Hilstad, Mark, “A Multi-Vehicle Testbed and Interface Framework for the Development and Verification of Separated Spacecraft Control Algorithms,” Master’s thesis, Massachusetts Institute of Technology, Department of Aeronautics and Astronautics, June 2002.

32

5. Honeywell International Inc., Inertial Sensor Products Redmond, “Q-Flex QA-160/185 Accelerometer,” http://www.inertialsensor.com/docs/qa-t160.pdf, 21 March 2002. 6. Miller, David W., et al., SPHERES critical design review, February 2002. 7. Murata Manufacturing Co., Ltd., MA40S4R online product specifications, Nov. 10, 2002, http://search.murata.co.jp/Ceramy/owa/CATALOG.showcatalog?sHinnmTmp=MA40S4R&s Lang=2&sNhnm=MA40S4R&sHnTyp=NEW. 8. Saenz-Otero, Alvar, “The SPHERES satellite formation flight testbed: Design and initial control,” Master's thesis, Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science, August 2000. 9. Sell, Steve, Payload Systems, Inc., personal contact.

14 Appendix A – GSP Package Contents • • •

• • • • •

The GSP interface document (this document) Pre-compiled SPHERES C libraries o spheres.lib Header files describing the library interfaces o com.h o ctrl.h o dbug.h o math.h o pads.h o prop.h o sys.h User-modifiable source code o gsp.c o gsp.h Example source code HTML template for test descriptions Simulation environment executable programs: o The GSP simulation server: gsp_server.exe. o The GSP simulation control panel: gsp_control.exe. The MATLAB data reduction script: spheres_reduce.m.

15 Appendix B – Document Change Log v1.0 (2002-11-20). The initial public release of this document.

33