SPHERES MIT Space Systems Laboratory Cambridge, MA 2006-Aug-08 Synchronized Position Hold, Engage, Reorient, Experimental Satellites ISS Test Session 2 Results

SPHERES 2 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 3 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 4 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

SPHERES 5 Operational Difficulties GUI 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 6 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

SPHERES 7 Operational Difficulties Low-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, 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 8 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

SPHERES 9 Program 101 Test 1.1 Flash 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 10 Program 101 Test 6 Closed-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 DataTest 6 Simulated Data

SPHERES 11 Program 101 Tests 14 & 16b Autonomous 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 16b Picture of satellite pointing at beacon

SPHERES 12 Program 112 Overview Fault 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 13 Program 112 Test 1 Failed-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 FDI Test 1 (Thruster on failure) results: gyro data and FDI resolutions

SPHERES 14 Program 112 Test 2 Failed-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 FDI Test 2 (Thruster off failure) results: gyro data and FDI resolutions

SPHERES 15 Program 112 Tests 3 & 4 Results 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 16 Program 112 Test 5 FDI 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 FDI Test 5 Results: Estimated Quaternion and FDI Resolutions

SPHERES 17 Program 113 Test 2 Position-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 18 Program 113 Test 3 MPC-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 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

SPHERES 19 Program 113 Test 15 Attitude 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 dataDesired trajectory

SPHERES 20 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 21 Consumables Consumption Efficient battery usage: –0h 20mSetup and program load –1h 26mRunning tests –0h 09mLow battery indicator –0h 07mReset conditions Minimal tank usage: –7%Running tests Available resources after Test Session 2 –Batteries must be replaced –Approximately 43% of tank

SPHERES 22 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 23 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 24 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 25 SPHERES Points of Contact Payload Integration: John Merk Payload Systems Inc. (617) x524 Principal Investigator: Prof. David Miller Director, MIT Space Systems Laboratory (617) Space Test Program (Code WR1): Maj Matthew Budde, USAF, (281) Mark Adams, SAIC, (281) Science Lead: Dr. Alvar Saenz-Otero MIT Space Systems Lab. (617) Graduate Students: Simon Nolet (PhD) Swati Mohan (MS) Nicholas Hoff (MS)

SPHERES 26 Revision History