SPHERES
Synchronized Position Hold, Engage, Reorient, Experimental Satellites
ISS Test Session 2 Results
MIT Space Systems Laboratory
Cambridge, MA
spheres-ops@mit.edu
2006-Aug-08
Payload Systems Inc
SPHERES
•
•
•
•
Test Session Objectives
Timeline Summary
Operational Difficulties
Results Analysis
–
–
–
–
–
–
–
•
•
•
•
•
•
Outline
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
Payload Systems Inc
2
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
Payload Systems Inc
3
SPHERES
•
•
•
•
•
Program Test
T 1.1
P101
T 1.1
T 1.1
T 1.1
T6
T 1.1
T 1.1
T 1.1
T6
T6
P112
(Ames)
P113
T 1.1
T6
T 14
T 14
T 16b
T1
T1
T2
T3
T3
T3
T4
T5
T1
T2
T2
T 15
T3
T8
T8
T 8.1
Description
Start time
Flash Memory Test
11:11:59
Flash Memory Test
11:15:06
Flash Memory Test
11:18:10
Close-loop XYZ rotation
11:19:01
Close-loop XYZ rotation
11:20:18
Flash Memory Test
11:28:37
Flash Memory Test
11:37:57
Flash Memory Test
11:39:31
Close-loop XYZ rotation
11:41:39
Close-loop XYZ rotation
11:45:55
SPHERES Satellite Reset by Crew
Flash Memory Test
11:48:45
Close-loop XYZ rotation
11:49:52
De-Tumble, Track, and Dock
11:55:15
De-Tumble, Track, and Dock
11:58:37
Dock Fixed Long S#2 PD
12:01:57
Failed-on thruster FDI
12:20:05
Failed-on thruster FDI
12:21:57
Failed-off thruster FDI
12:23:17
Multiple thruster FDI
12:31:59
Multiple thruster FDI
12:33:57
Multiple thruster FDI
12:34:58
Closed loop attitude control
12:36:41
FDI with attitude control
12:40:03
Quick checkout
12:48:55
Basic Position Hold
12:50:24
Basic Position Hold
12:51:24
Attitude path following
12:57:45
Stationkeeping 3D – 1
13:01:34
De-tumble, Track, & Dock
13:03:58
De-tumble, Track, & Dock
13:05:26
De-tumble, Track, & Dock
13:08:15
Interval
03:07
03:04
00:51
01:17
08:19
09:20
01:34
02:08
04:16
02:50
Payload Systems Inc
4
01:07
05:23
03:22
03:20
08:00
01:52
01:20
08:42
01:58
01:01
01:43
03:22
02:57
01:29
01:00
06:21
03:49
02:24
01:28
02:49
01:00
Notes
Communication Problems
•
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
Low
Battery
•
Timeline Summary
Operational Difficulties
GUI Configuration
SPHERES
• 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
Payload Systems Inc
5
SPHERES
Operational Difficulties
Dropped 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
Payload Systems Inc
6
Operational Difficulties
Low-Battery Conditions
SPHERES
• 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
Payload Systems Inc
7
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: Autonomous
docking,
Prog. 113 Tests 8 & 18: Autonomous docking
Payload Systems Inc
8
Program 101 Test 1.1
Flash Memory Checkout
SPHERES
• 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:
Payload Systems Inc
9
Program 101 Test 6
Closed-Loop XYZ Rotations
SPHERES
•
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
Payload Systems Inc
10
Program 101 Tests 14 & 16b
Autonomous Docking
SPHERES
•
•
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)
Picture of satellite pointing at beacon
Estimated Stated during Test 16b
Payload Systems Inc
11
Program 112 Overview
Fault Detection and Isolation
SPHERES
• Objective:
– Demonstrate the ability to identify failures using estimated massproperties 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
Payload Systems Inc
12
Program 112 Test 1
Failed-on Thruster FDI
SPHERES
•
No thruster commands issued by the controller
At ~10s a low-level function tells thruster #3 to turn on to simulate a thrusteron 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
Filtered angular rates
Thruster Commands
0.3
0.25
0.2
omega [rad/sec]
•
•
T 12
Command, no fault
wx
T 11
Fault present
wy
T 10
wz
T9
Excitation - off
T8
Excitation - on
0.15
T7
0.1
On fault active
FDI reset
Fault detected
T6
0.05
T5
Fault isolated
Disturbance
T4
0
T3
-0.05
-0.1
0
Off fault active
T2
T1
2
4
6
8
time [sec]
10
12
14
16
0
2
4
6
8
time [sec]
10
12
FDI Test 1 (Thruster on failure) results: gyro data and FDI resolutions
Payload Systems Inc
13
14
16
Program 112 Test 2
Failed-off Thruster FDI
SPHERES
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
Filtered angular rates
Thruster Commands
0.05
Fault present
On fault active
Excitation - off
T8
Excitation - on
FDI reset
Fault detected
T6
Fault isolated
T5
Disturbance
wx
wy
T3
2
Off fault active
T9
T4
T2
wz
-0.15
0
Command, no fault
T 11
T7
-0.05
-0.1
T 12
T 10
0
omega [rad/sec]
•
•
•
•
T1
4
6
8
time [sec]
10
12
14
16
0
2
4
6
8
time [sec]
10
12
14
FDI Test 2 (Thruster off failure) results: gyro data and FDI resolutions
Payload Systems Inc
14
16
Program 112 Tests 3 & 4
Results
SPHERES
• 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
Payload Systems Inc
15
Program 112 Test 5
FDI with attitude control
SPHERES
•
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
PADS-estimated quaternion
Thruster Commands
1
quaternion [ ]
•
•
•
0.5
T 12
Command, no fault
q1
T 11
Fault present
q2
T 10
q3
T9
Excitation - off
q4
T8
Excitation - on
T7
Off fault active
On fault active
FDI reset
Fault detected
T6
T5
0
Fault isolated
Disturbance
T4
T3
T2
T1
-0.5
0
5
10
15
time [sec]
20
25
0
5
10
15
20
time [sec]
FDI Test 5 Results: Estimated Quaternion and FDI Resolutions
Payload Systems Inc
16
25
Program 113 Test 2
Position-Hold
SPHERES
•
–
–
•
Validate estimation algorithms
Demonstrate the ability to maintain
position and attitude
–
–
Successful test
–
Utilizes a single beacon (ultrasound
transmitter) and the satellite’s
gyroscopes to estimate the 6DOF
state of the satellite
–
•
•
Objectives:
–
–
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
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
Payload Systems Inc
17
Program 113 Test 3
MPC-based Position Hold
SPHERES
•
•
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 of
double-speed video for the preview;
the video is double speed to reduce
the file size and minimize the crew
time needed to review the test
description
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
Payload Systems Inc
18
Program 113 Test 15
Attitude trajectory tracking
SPHERES
•
•
•
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
Payload Systems Inc
19
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
Payload Systems Inc
20
SPHERES
Consumables Consumption
• Efficient battery usage:
–
–
–
–
0h 20m
1h 26m
0h 09m
0h 07m
Setup and program load
Running tests
Low battery indicator
Reset conditions
• Minimal tank usage:
– 7%
Running tests
• Available resources after Test Session 2
– Batteries must be replaced
– Approximately 43% of tank
Payload Systems Inc
21
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
Payload Systems Inc
22
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
Payload Systems Inc
23
SPHERES
•
•
•
•
•
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
–
•
•
•
•
•
Actions
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
Payload Systems Inc
24
SPHERES
SPHERES Points of Contact
spheres-ops@mit.edu
Principal Investigator:
Science Lead:
Prof. David Miller
Director, MIT Space Systems Laboratory
(617) 253-3288
millerd@mit.edu
Payload Integration:
Dr. Alvar Saenz-Otero
MIT Space Systems Lab.
(617) 324-6827
alvarso@mit.edu
Graduate Students:
John Merk
Payload Systems Inc.
(617) 868-8086 x524
merk@payload.com
Simon Nolet (PhD)
snolet@mit.edu
Swati Mohan (MS)
smohan@mit.edu
Space Test Program (Code WR1):
Maj Matthew Budde, USAF, (281) 483-7576
Mark Adams, SAIC, (281) 483-3520
Nicholas Hoff (MS)
nhoff@mit.edu
Payload Systems Inc
25
SPHERES
Date
2006/Aug/08
Version
1.0
Revision History
Notes
Initial release
Released by
alvarso
Payload Systems Inc
26