SPHERES MIT Space Systems Laboratory Cambridge, MA [email protected] 2006-Aug-08 Synchronized...

SPHERES

Payload Systems Inc

MIT Space Systems Laboratory

Cambridge, MA

[email protected]

2006-Aug-08

Synchronized Position Hold, Engage, Reorient, Experimental Satellites

ISS Test Session 2 Results

SPHERES

Payload Systems Inc2

Outline• Test Session Objectives• Timeline Summary• Operational Difficulties• Results Analysis

– Program 101 Test 1.1: Flash memory checkout

– Program 101 Test 6: Closed-loop XYZ rotations

– Program 101 Tests 14 & 16b: Autonomous docking experiments

– Program 112: Fault Detection, Isolation, and Recovery experiments

– Program 113 Tests 2 & 3: Position-hold experiments

– Program 113 Test 15: Attitude trajectory tracking

– Program 113 Tests 8 & 8.1: Autonomous docking experiments

• Consumables consumption• Conclusions• Lessons Learned• Future Actions• Points of Contact• Revision History

SPHERES


Test Session Objectives• Original objectives changed after the first test session

– Moved the “Mass-ID” test to a future session

– Performed “FLASH Check” test and demonstrated closed-loop rotations

• Therefore, the new objectives were:– FLASH memory fix

– Closed-loop attitude control demonstrations

– FDIR algorithm demonstrations

– Maneuvers for autonomous docking demonstration• Position estimation and control tests

• Translation control tests

• De-tumbling, tracking, and glideslope maneuvers

• The estimation and control algorithms will form part of the Guest Scientists Program to facilitate the use of SPHERES by investigators outside of the MIT SSL

SPHERES


Timeline Summary• Start: 11:00GMT (06:00CDT)

Saturday 20-May-2006 “Saturday Science”

• Started slightly ahead of scheduled time

• Hardware locate, program load: ~20m

• First test: ~11:10GMT

• Total tests: 31

• Total time: 1h 42m

• Avg. time per test: 3m16s

Program Test Description Start time Interval NotesP101 T 1.1 Flash Memory Test 11:11:59 03:07

T 1.1 Flash Memory Test 11:15:06 03:04T 1.1 Flash Memory Test 11:18:10 00:51T 1.1 Close-loop XYZ rotation 11:19:01 01:17T 6 Close-loop XYZ rotation 11:20:18 08:19T 1.1 Flash Memory Test 11:28:37 09:20T 1.1 Flash Memory Test 11:37:57 01:34T 1.1 Flash Memory Test 11:39:31 02:08T 6 Close-loop XYZ rotation 11:41:39 04:16T 6 Close-loop XYZ rotation 11:45:55 02:50 C

omm

unic

atio

n P

robl

ems

SPHERES Satellite Reset by CrewT 1.1 Flash Memory Test 11:48:45 01:07T 6 Close-loop XYZ rotation 11:49:52 05:23T 14 De-Tumble, Track, and Dock 11:55:15 03:22T 14 De-Tumble, Track, and Dock 11:58:37 03:20T 16b Dock Fixed Long S#2 PD 12:01:57 08:00

P112 T 1 Failed-on thruster FDI 12:20:05 01:52(Ames) T 1 Failed-on thruster FDI 12:21:57 01:20

T 2 Failed-off thruster FDI 12:23:17 08:42T 3 Multiple thruster FDI 12:31:59 01:58T 3 Multiple thruster FDI 12:33:57 01:01T 3 Multiple thruster FDI 12:34:58 01:43T 4 Closed loop attitude control 12:36:41 03:22T 5 FDI with attitude control 12:40:03 02:57

P113 T 1 Quick checkout 12:48:55 01:29T 2 Basic Position Hold 12:50:24 01:00T 2 Basic Position Hold 12:51:24 06:21T 15 Attitude path following 12:57:45 03:49T 3 Stationkeeping 3D – 1 13:01:34 02:24T 8 De-tumble, Track, & Dock 13:03:58 01:28T 8 De-tumble, Track, & Dock 13:05:26 02:49T 8.1 De-tumble, Track, & Dock 13:08:15 01:00

Low

Bat

tery

SPHERES


Operational DifficultiesGUI Configuration

• The GUI believed the satellite was “blue” instead of “red”– Issue also present during first test session, but had full custom

procedures for that session– The full procedures were not transmitted by the SPHERES team to

ensure smooth operations using the pre-loaded code– Initially the crew “closed” the load window (as per normal

procedures) indicating the use of the “red” satellite, even though the special procedures to select the “blue” satellite should have been provided to the crew

• The satellite did not respond to any commands

– Ultimately crew followed full procedures of the first test-session• Reloaded the code already on the satellite

SPHERES


Operational DifficultiesDropped Communication Packets

• After loading the program the satellite continuously dropped communication packets– It was not possible to run tests:

• Satellite disabled itself before the crew could start a test with the GUI, or• Satellite terminated the tests before their completion

• Real-time evaluation (confirmed by subsequent analysis) showed a high rate of incomplete packets

• Problem solved by crew’s initiative to reset the satellite manually

• Anomaly Report has been submitted to NASA– Weak communication is a known issue with the backup LPTX box

available during this test session; this problem will likely be solved by the use of the main box after delivery on STS-121

SPHERES


Operational DifficultiesLow-Battery Conditions

• Nominal operations: the crew should operate the satellite continuously until the battery is depleted to the point it can no longer run tests– Low-battery indicator is a “heads-up” when it turns on, 10-20 minutes of

operations should be expected from that moment

– Satellite reset repeatedly when a test is started and battery is too low

• During the test session it was clear the low-battery indicator was not noticed by the crew for approximately 16 minutes– The LED / GUI indicator was on ~9 minutes before the satellites began to

reset

– The satellite reset during four tests (~7 minutes) before the crew noticed the low-battery status

• Crew concentrated on the “test control area”– Desired area of concentration within the GUI

– SPHERES team must provide crew feedback in that area

SPHERES


Results Analysis Overview• The tests ran during this session correspond to the mission objectives as

follows:– FLASH Memory Prog. 101 Test 1.1: Flash Memory Test

– Closed-loop control Prog. 101 Test 6: Closed-loop XYZ rotations

– FDIR algorithms Prog. 112, all tests

– Position control Prog. 113 Tests 2 & 3: Position Hold

– De-tumbling, tracking Prog. 113 Test 15: Attitude trajectory tracking

– Docking maneuvers Prog. 101 Tests 14 & 16b: Autonomousdocking,Prog. 113 Tests 8 & 18: Autonomous docking

SPHERES


Program 101 Test 1.1Flash Memory Checkout

• Objective: determine if the FLASH memory value are incorrect, and if so, attempt to correct them

• Ultimately returned code “11”:– Memory was corrupted (value larger than 10)– Memory was fixed after one try (# of tries = return - 10)

• The downloaded data during this test shows the following corruption of the scaling factors:

SPHERES


Program 101 Test 6Closed-Loop XYZ Rotations

• Objectives– Demonstrate closed-loop attitude control

– Confirm that FLASH corruption was the problem during TS1

• Results– There was overshoot and undershoot in the rotations

– The final errors are within the expected deadband given the controller configuration• Bandwidth set to approximately 0.3rad/s, damping coefficient 1.0• Minimum thruster pulse of 10ms (hardware limited)

– Behavior confirmed with simulation

Test 6 Downloaded Data Test 6 Simulated Data

SPHERES


Program 101 Tests 14 & 16bAutonomous Docking

• Objectives: demonstrate docking maneuvers towards a SPHERES beacon

• Test ran three times– The first two times the estimator did not converge– The third time the docking maneuver worked partially

• Deployment was too close to the beacon (~35cm instead of 2m)• Was unable to stop after it reached a range of 10cm at too high a speed• Successfully estimated data and pointed to beacon for an extended period of time (~90s)

Estimated Stated during Test 16bPicture of satellite pointing at beacon

SPHERES


Program 112 OverviewFault Detection and Isolation

• Objective:– Demonstrate the ability to identify failures using estimated mass-

properties and expected response to actuation of the satellite– Determine the overhead of FDI algorithms during nominal control

• FDI algorithms implemented in Embedded C++ with custom SPHERES Core software

• Consists of five tests:– 3 basic tests– “Control” test– Closed-loop control with FDI in the background

SPHERES


Program 112 Test 1Failed-on Thruster FDI

• No thruster commands issued by the controller

• At ~10s a low-level function tells thruster #3 to turn on to simulate a thruster-on failure (thruster is on when it should not be)

• Test succeeded:– Steady rotation rate after 0.4s indicates the fault was detected and isolated by

commanding the low-level function to turn the thruster off– Otherwise the rotation rate would have increased for six seconds

0 2 4 6 8 10 12 14 16-0.1

-0.05

0

0.05

0.1

0.15

0.2

0.25

0.3

time [sec]

om

ega

[ra

d/s

ec]

Filtered angular rates

wx

wy

wz

0 2 4 6 8 10 12 14 16

T 1

T 2

T 3

T 4

T 5

T 6

T 7

T 8

T 9

T 10

T 11

T 12

time [sec]

Thruster Commands

Command, no fault

Fault present

Off fault active

On fault active

Excitation - off

Excitation - on

FDI reset

Fault detected

Fault isolated

Disturbance

FDI Test 1 (Thruster on failure) results: gyro data and FDI resolutions

SPHERES


Program 112 Test 2Failed-off Thruster FDI

• Thrusters #3 and #9 alternate firing once per second• At 10.0s a thruster #3 off-failure is simulated• At 10.9s thruster #3 is commanded to fire, but does not• At 11.0s the FDI algorithm detects the failure

– Multiple candidates existed:• #3 off failure• #4 or #9 on failure

– Scheduled an excitation at next possible time (before 11.2s) to isolate #3 off failure

0 2 4 6 8 10 12 14 16-0.15

-0.1

-0.05

0

0.05

time [sec]

om

ega

[rad

/sec

]

Filtered angular rates

wx

wy

wz

0 2 4 6 8 10 12 14 16

T 1

T 2

T 3

T 4

T 5

T 6

T 7

T 8

T 9

T 10

T 11

T 12

time [sec]

Thruster Commands

Command, no fault

Fault present

Off fault active

On fault active

Excitation - off

Excitation - on

FDI reset

Fault detected

Fault isolated

Disturbance

FDI Test 2 (Thruster off failure) results: gyro data and FDI resolutions

SPHERES


Program 112 Tests 3 & 4Results

• Test 3: Multiple-thruster FDI– Commanded two failures during the same test at different time

• Test online reset of FDI algorithm after detecting a failure

– Successfully detected the first failure– Test stopped prematurely due to communication losses

• Test 4: Closed-loop Attitude Control– Serve as a “control” test to ensure the implemented algorithm can

perform closed-loop attitude control before attempting control and FDI at the same time

– Successfully performed the maneuvers to within the required performance

• Stable controller• Normal thruster firing

– Possible to continue to next test

SPHERES


Program 112 Test 5FDI with attitude control

• The satellite is commanded to perform attitude-hold– An initial offset causes excitation of the satellite

• While performing attitude-hold, thruster #3 is failed-off at 10.0s

• At 11.7s the thruster is commanded to fire by the attitude controller

• At 12.1s the fault is detected and isolated (thrusters #3 and #9 are no longer allowed to fire) until approximately 24s

0 5 10 15 20 25-0.5

0

0.5

1

time [sec]

qu

ater

nio

n [

]

PADS-estimated quaternion

q1

q2

q3

q4

0 5 10 15 20 25

T 1

T 2

T 3

T 4

T 5

T 6

T 7

T 8

T 9

T 10

T 11

T 12

time [sec]

Thruster Commands

Command, no fault

Fault present

Off fault active

On fault active

Excitation - off

Excitation - on

FDI reset

Fault detected

Fault isolated

Disturbance

FDI Test 5 Results: Estimated Quaternion and FDI Resolutions

SPHERES


Program 113 Test 2Position-Hold

• Objectives:– Validate estimation algorithms– Demonstrate the ability to maintain

position and attitude

• Utilizes a single beacon (ultrasound transmitter) and the satellite’s gyroscopes to estimate the 6DOF state of the satellite

– Extended Kalman Filter used to estimate states

– Requires that the satellite maintains attitude

– Gyroscope drift affects performance (~5deg/min)

• Timeline:– t=~10s convergence– t=~15s change orientation– t=~150s position hold

• Successful test– Satellite performed 3D rotation to point

at beacon and held position for an extended period of time

– Performance well within desired range

– Minimal thruster activity (as expected), but enough to produce noticeable deadband in fast-forwarded video

SPHERES


Program 113 Test 3MPC-based Position Hold

• Model-Predictive Control (MPC) algorithm to maintain position

• After initial deployment satellite was to position-hold for one minute, then be slightly disturbed by the crew

– The disturbance occurred too early (35s), too often (35s, 41s, 44s, 58s), and was too large for the satellite to respond given the controller settings

• This is potentially due to the use ofdouble-speed video for the preview;the video is double speed to reducethe file size and minimize the crewtime needed to review the testdescription

• Partial success– Test results show attempts to

return to the original position– Attitude maintained reasonably

well given disturbance magnitude– Satellite reset at t=61s due

to low batteries

SPHERES


Program 113 Test 15Attitude trajectory tracking

• Objective: follow an attitude trajectory• Designed as a “sun avoidance” trajectory, i.e., avoid pointing in a specific direction• Successful test:

– Desired trajectory closely matched downloaded data and observed motion in the video

– Used similar controller as Program 101 Test 6, but used different parameters to have better response (closer tracking)

Downloaded data Desired trajectory

SPHERES


Program 113 Tests 8 & 8.1

• Objectives:– Validate the 6DOF estimator for use in tracking maneuvers– Demonstrate docking maneuvers to a SPHERES beacon

• These tests did not complete due to a low-battery condition– The satellite reset every time thrusters were commanded to fire– Nominal and expected behavior

SPHERES


Consumables Consumption

• Efficient battery usage:– 0h 20m Setup and program load– 1h 26m Running tests– 0h 09m Low battery indicator– 0h 07m Reset conditions

• Minimal tank usage:– 7% Running tests

• Available resources after Test Session 2– Batteries must be replaced– Approximately 43% of tank

SPHERES


Conclusions

• Successfully provided large amounts of data to evaluate estimation and control algorithms– Estimation algorithms perform with high accuracy– Estimation algorithms conceptual basis proved correct– Demonstrated good understanding of control algorithm

performance and their parameters

• Must still demonstrate translational control– Full set of docking maneuvers not yet complete

SPHERES


Lessons Learned

• Communication problems prevented a large number of tests from running– A manual reset of the satellite can fix some problems

• The crew does not have enough feedback during a test to realize the low-battery status

• The crew specifically requested a “cheat-sheet” or “quick-start” guide for SPHERES

• The initiatives of the crew saved substantial time– The SPHERES team must capture these actions into documents

to help future expeditions

SPHERES


Actions• An updated GUI configuration file (gui.ini) has been loaded to the ISS SSCs which correctly

identifies the colors of the satellites

• The GUI executable has been updated to search for a “gui.ini” configuration in the “data directory” specified by the default “gui.ini” so that future changes can be made without the need to wait for a SSC general update

• The GUI executable has been updated to indicate to the crew when a program is already loaded in the satellite

• The programs for the SPHERES satellites have been updated to transmit the state of the GUI at 5Hz instead of 1Hz, greatly reducing the probability of the GUI detecting a loss of communication with a satellites (must loose 14 packets in a row, rather than 2)

• The SPHERES GUI no longer stops a test when it does not receive data from a satellite; it informs the crew of this status and waits for crew to take action

– The satellite will stop a test if it looses communication from the GUI, as required by safety procedures

• The main LPTX box was delivered by STS-121

• The SPHERES core software has been updated to automatically recognize the use of the main LPTX box or the backup LPTX box

• The closed-loop critical path values will continue to be uploaded with each program until further notice

• The SPHERES core software now returns “result code” 255 (0xFF) when the satellite resets, as a clear indication within the “test control” area that a reset occurred

• The “test overview” format has been revised to include detailed deployment information

SPHERES


SPHERES Points of Contact

Payload Integration:John MerkPayload Systems Inc.(617) 868-8086 [email protected]

Principal Investigator:Prof. David Miller

Director, MIT Space Systems Laboratory

(617) 253-3288

[email protected]

Space Test Program (Code WR1):Maj Matthew Budde, USAF, (281) 483-7576

Mark Adams, SAIC, (281) 483-3520

Science Lead:Dr. Alvar Saenz-Otero

MIT Space Systems Lab.

(617) 324-6827

[email protected]

Graduate Students:Simon Nolet (PhD)

[email protected]

Swati Mohan (MS)

[email protected]

Nicholas Hoff (MS)

[email protected]

[email protected]

SPHERES


Revision History

Date Version Notes Released by2006/Aug/08 1.0 Initial release alvarso

SPHERES MIT Space Systems Laboratory Cambridge, MA [email protected] 2006-Aug-08 Synchronized...

Documents

Transcript of SPHERES MIT Space Systems Laboratory Cambridge, MA [email protected] 2006-Aug-08 Synchronized...