MIT Space Systems Laboratory

1
Synchronized Position Hold, Engage, Reorient,
Experimental Satellites ISS Test Session 2
Results

• MIT Space Systems Laboratory
• Cambridge, MA
• spheres-ops_at_mit.edu
• 2006-Aug-08

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

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

4
Timeline Summary

• Start 1100GMT (0600CDT) Saturday 20-May-2006
  Saturday Science
• Started slightly ahead of scheduled time
• Hardware locate, program load 20m
• First test 1110GMT
• Total tests 31
• Total time 1h 42m
• Avg. time per test 3m16s

5
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

6
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 crews 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

7
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

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

9
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

10
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
11
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)

Picture of satellite pointing at beacon
Estimated Stated during Test 16b
12
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

13
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

FDI Test 1 (Thruster on failure) results gyro
data and FDI resolutions
14
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

FDI Test 2 (Thruster off failure) results gyro
data and FDI resolutions
15
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

16
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

FDI Test 5 Results Estimated Quaternion and FDI
Resolutions
17
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 satellites 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
• t10s convergence
• t15s change orientation
• t150s 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

18
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 previewthe video
  is double speed to reducethe file size and
  minimize the crewtime needed to review the
  testdescription
• Partial success
• Test results show attempts toreturn to the
  original position
• Attitude maintained reasonablywell given
  disturbance magnitude
• Satellite reset at t61s dueto low batteries

19
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
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

21
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

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

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

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

25
SPHERES Points of Contact
spheres-ops_at_mit.edu

• Principal Investigator
• Prof. David Miller
• Director, MIT Space Systems Laboratory
• [phone]
• millerd_at_mit.edu

Science Lead Dr. Alvar Saenz-Otero MIT Space
Systems Lab. [phone] alvarso_at_mit.edu
Payload Integration John Merk Payload Systems
Inc. [phone] x524 merk_at_payload.com
Graduate Students Simon Nolet (PhD) snolet_at_mit.ed
u Swati Mohan (MS) smohan_at_mit.edu Nicholas Hoff
(MS) nhoff_at_mit.edu
Space Test Program (Code WR1) Maj Matthew Budde,
USAF, [phone] Mark Adams, SAIC, (281)
483-3520
26
Revision History