Expanding the Comprehensive Open-architecture Space Mission Operations System (COSMOS) for Integrated Guidance, Navigation and Control of Multiple Small Satellites

Abstract

The idea of using multiple small satellites is becoming very attractive for future space missions. As a consequence the cooperative motion for teams of autonomous small space-craft systems is also becoming increasingly important for maneuvers such formation ying, docking and proximity operations for small satellites. This paper describes the work we have developed to address some of these problems by creating an integrated framework for Guidance, Navigation and Control (iGNC) for two satellites using the Comprehensive Open-architecture Space Mission Operations System (COSMOS). We also present a new guidance law that optimizes fuel consumption for the two-satellite system. An important outcome of this work is the development of a comprehensive software that extends the iGNC framework to almost ight-ready software that is modular and easy to improve, and can also be used for mission simulation rehearsals.

Full text

Expanding the Comprehensive Open-architecture
Space Mission Operations System (COSMOS) for
integrated Guidance, Navigation and Control of
Multiple Small Satellites
Miguel A. Nunes
∗
, Trevor C. Sorensen
†
, Eric J. Pilger
‡
,
Mark Wood
§
, Harold M. Garbeil
¶
, James R. Lewis
k
,
Dilmurat M. Azimov
∗∗
The idea of using multiple small satellites is becoming very attractive for future space
missions. As a consequence the cooperative motion for teams of autonomous small space-
craft systems is also becoming increasingly important for maneuvers such as formation
flying, docking and proximity operations for small satellites. This paper describes the
foundational work we have developed to address some of these problems by creating an
integrated framework for Guidance, Navigation and Control (iGNC) for two satellites using
the Comprehensive Open-architecture Space Mission Operations System (COSMOS). We
also present a new guidance law that optimizes fuel consumption for the two-satellite sys-
tem. An important outcome of this work is the development of a comprehensive software
that extends the iGNC framework to almost flight-ready software that is modular and easy
to improve, and can also be used for mission simulation rehearsals.
I. Introduction
There is an ongoing effort to reduce the cost of small satellites and to increase their capabilities therefore
increasing the expectations of space exploration by using multiple satellites. This will consequently enable in
the near future new space missions that have not been possible previously because of budgetary constraints
or even technical limitations. For future satellite missions, the efficient means for motion coordination of
spacecraft will enable capabilities such as large space telescopes, solar arrays, satellite servicing stations, etc..
The Hawaii Space Flight Laboratory (HSFL) at the University of Hawaii at Manoa is developing the ca-
pabilities to design, build, and operate small satellites within the paradigm mentioned of cost reduction.
1
With the Operationally Responsive Space (ORS) Office, HSFL is developing the Super Strypi launch vehicle
that is capable of launching satellites into a near polar orbit at a significant cost reduction. More recently
HSFL has also been involved in multiple studies for the use of satellite constellations for Earth Observations.
We have developed optimization methods for satellite constellations
2
observing sections of the globe, we
have also developed efficient methods for orbital separation of multiple satellites and a method to efficiently
deploy a constellation of small satellites using a minimal number of launch vehicles.
3
These methods are
enabling the study of space missions that have never before been contemplated.
∗
Ph.D. Candidate - Research Assistant, Hawaii Space Flight Laboratory, 1680 East-West Rd. POST 501, Honolulu, HI,
96822, AIAA Student Member.
†
Specialist Professor, Hawaii Space Flight Laboratory, 1680 East-West Rd. POST 501, Honolulu, HI, 96822, AIAA Fellow.
‡
Lead Software Engineer, Hawaii Space Flight Laboratory, Honolulu, HI, 96822.
§
Software Engineer, Hawaii Space Flight Laboratory, Honolulu, HI, 96822.
¶
Software Engineer, Hawaii Institute of Geophysics and Planetology, Honolulu, HI, 96822.
k
Software Engineer, Hawaii Space Flight Laboratory, Honolulu, HI, 96822.
∗∗
Assistant Professor, Mechanical Engineering, Honolulu, HI, 96822, AIAA Professional Member.
1 of 15
American Institute of Aeronautics and Astronautics

The HSFL team has also been developing the Comprehensive Open-architecture Space Mission Operations
System (COSMOS) with a three-year NASA ESPCoR grant. COSMOS is intended to be a unified frame-
work for mission operations, not only for the ground operations, but also at the satellite level.
4
Considering
future space missions scenarios, COSMOS is being designed to support multiple satellites. COSMOS is
currently being expanded as a System of Systems (SoS) integrator, tying together multiple systems such
as ground stations, satellites and even mission operations servers. One of the goals of COSMOS is that it
should be easily adaptable to new architectures and easily scalable. In previous papers we have explained
how COSMOS can be used for satellite remote sensing missions
43
, for rover missions,
5
and more recently
we started looking into the operations of multiple satellites.
6
The development of the COSMOS framework to operate and control a large number of satellites is so that
simulation scenarios can be replicated in accelerated or real time for design studies, operations training and
also for research. COSMOS is being prepared to become a unified software framework not only for mission
control operations tools, but also for ground stations and flight software. The first part of this paper explains
the COSMOS software architecture that enables a multiple satellite mission. For the second part of this
paper we present a simulation scenario for rendezvous of two satellites using the COSMOS architecture.
This rendezvous simulation is based on an integrated Guidance, Navigation and Control (iGNC) framework
that is incorporated into the COSMOS software.
II. COSMOS Software Architecture
COSMOS is a suite of software and hardware tools (including external modules) that enables the operations
team to interface with the spacecraft, ground control network, payload and other customers in order to per-
form the mission operations functions including mission planning and scheduling; contact operations; data
management and analysis; simulations (including the operational testbed); ground network control; payload
operations; flight dynamics; and system management. COSMOS is being designed to easily be adapted for
new spacecraft or installation in new mission operations centers (MOCs). Some of the basic elements of
COSMOS have been developed at least to the prototype stage, while other elements are still in the develop-
ment stage. The COSMOS tools will initially be installed in the HSFL and ARC MOCs and used in support
of three of their small satellites.
COSMOS is primarily a software framework but it also contains some hardware elements. It’s the seamless
combination of software and hardware that enables us to address all phases of the spacecraft lifecycle with
a more integrated approach; for the design, development, testing, implementation, and operations. In its
current development stage COSMOS provides elements for the creation of fully interactive simulators, test
beds, and flight and operations software. COSMOS works from the lowest level math calculations through
the coordination of multiple intercommunicating processes with a high level graphical user interface. It’s
tailored for embedded processors and also more powerful computing machines. A wide array of libraries and
programs are provided to make this possible, most of which work on any Linux, MacOS or Windows platform.
The COSMOS software has adopted a paradigm that empowers a generic and modular approach for software
re-usability, if this paradigm is implemented then the software becomes “COSMOS-aware”. The COSMOS
software can be installed on a satellite, a ground station, rover, a server, etc.. These are refered to as
COSMOS “Nodes”. Although nodes differ in their hardware and functional purpose they may share common
information elements such as bus voltage, position vector, etc. COSMOS nodes become live with COSMOS
software “agents”, these are self aware computer programs that receive commands and send data in a
standardized way. The COSMOS “Tools” are the data receiving terminals and command controls for the
mission.
For this particular project we developed COSMOS software agents, one for each satellite, that report the
dynamics and receive state information for proper guidance of each satellite. Figure 1 shows a diagram of the
COSMOS software implementation for this particular problem. We also developed a Ground Station Agent
that receives and forwards the dynamic state information and state-of-health information. The Mission
Operations Center Server Agent receives and stores all the data from the satellite and receives and forwards
the mission control information from the Operations Center. Finally we configured the COSMOS Tools,
2 of 15
American Institute of Aeronautics and Astronautics

MOST and CEO, to visualize and control the two satellites. The next sections will explain in more detail
the COSMOS software structure.
Figure 1. COSMOS operations diagram
A. COSMOS Paradigm
COSMOS is based on a limited number of key design elements, put together in a layered approach. These
key elements are based as much as possible on existing protocols and approaches. The foundation of COS-
MOS consists of a set of libraries supporting the various functionalities available in the suite. This includes
mathematical functions, and orbital and coordinate calculations, protocol support, and hardware and simu-
lation support for the Operations Test Bed (which will help test and verify command loads before they are
uploaded to the satellites). The underlying key elements of the COSMOS paradigm are:
• A universal COSMOS software namespace that contains every item that might be of interest to any
part of the system.
• The COSMOS namespace is expressed internally as set of mappings between names and variables, and
functions for utilizing these mappings.
• The COSMOS namespace is expressed externally through JavaScript Object Notation (JSON).
• Programs performing related functionality are grouped together as Nodes, sharing an identical names-
pace.
3 of 15
American Institute of Aeronautics and Astronautics

• Programs communicate the current state of these variables with each other, and between Nodes,
through the external JSON representation, and a specialized protocol for inter-program communication.
In addition, COSMOS programs can take advantage of various unique data types and supporting functions
common to COSMOS.
B. COSMOS Libraries
The foundation of COSMOS is its set of libraries that provide support for the various algorithms and pro-
tocols that have been either adopted, or created to support COSMOS. The code conforms to the C++11
standard as defined (in the lowest common denominator) by G++, MinGW, and Clang. Where possible,
subtle differences in calling conventions have been accommodated for with COSMOS specific defines. More
than 95% of the code currently works on all three major operating systems.
An exhaustive list will not be provided here, but the libraries support both general purpose functionality,
such as vector and matrix math, coordinate conversion and standard protocol support; higher level function-
ality, such as orbital propagation, curve fitting, ephemeris and magnetic and gravitational modeling; and
functions very specific to COSMOS, such as Agent creation and communication, JSON based encoding and
decoding.
The libraries provide the “glue” that holds together COSMOS aware programs, COSMOS Agents and
COSMOS Tools.
C. COSMOS Programs
As mentioned above, any standard program can be brought in to the COSMOS fold through adoption of
the COSMOS paradigm, and through use of the special functions provided by the COSMOS libraries. At
the basic level, a COSMOS aware program will be able to sense the data being passed by other COSMOS
aware programs. Using the COSMOS libraries, this COSMOS ”Client” will be able to gather data, decode
it, convert it to other useful forms, and send out its own data. For extended functionality, it will be able
to communicate with special COSMOS servers also named COSMOS ”Agents”, requesting them to perform
specialized functions.
D. COSMOS Agents
COSMOS Agents are special persistent COSMOS aware programs that, through a special protocol defined
for COSMOS, can field requests from other COSMOS aware programs. They are, by their nature, multi-
threaded. One thread handles incoming requests, while a second thread delivers a regular ”Heartbeat” to
the local network, consisting of uniquely identifying information, plus a predefined set of ”State of Health”
information. Finally, a main thread allows for the performance of any repeated actions, including special
algorithms, communication with other Agents, and the broadcasting of additional data.
E. COSMOS Tools
Visualization is an important aspect of the COSMOS environment. We have chosen the open Qt Development
Environment, currently owned by Digia, as the basis for all our graphical user interface work. In combination
with the COSMOS libraries, Qt has allowed us to start work on a suite of special GUI based COSMOS aware
programs that provide windows in to any COSMOS environment. A number of COSMOS Tools have been
developed and are described in the next sections.
1. Mission Operations Support Tool (MOST)
A pair of programs, MOST and the Mission Planning and Scheduling Tool (MPST), are designed as the
primary Mission Operations Tools. MOST, while providing some capability for communicating, serves the
primary purpose of analyzing incoming telemetry to provide visualization of the current state of health of
the vehicle or “node”, as well as its context with respect to other vehicles and the ground. Any variable in
the COSMOS namespace can be configured to be displayed graphically, pictorially or tabularly. Particular
4 of 15
American Institute of Aeronautics and Astronautics

instances of MOST can be tuned to particular missions, taking advantage of specialized subsystem screens.
The entire operation of MOST is time based, allowing for either real time viewing, or playback at variable
speeds. MOST is based on the LUNOPS program that was developed to support both LEO and lunar
operations for the Clementine mission in 1994.
7
MOST can be used for supporting the following major operations functions: (1) vehicle (node) and payload
monitor & control; (2) mission planning; (3) simulations and rehearsals; (4) trending and analysis; and (5)
anomaly resolution. Although MOST can be used for many different types of nodes (vehicles), its most
common usage is with spacecraft and so where we state ”spacecraft” or ”satellite” in this paper, it can be
any vehicle.
The MOST overview screen (cf. Figure 2) has five basic functions. (1) Displays a timeline with past and
future events, including loaded commands. (2) Displays subsystem and payload status. (3) Provides a
visual/graphical display of the satellite position and attitude. (4) Detects anomalies and display warnings
pertinent to spacecraft conditions. (5) Sends real-time commands to the spacecraft.
The MOST display consists of a timeline chart, several diagrams and text boxes, and two 3D windows. The
timeline chart (Mission Events Display) shows the past and future events, both orbit related and command
related, with countdown (or countup) times for the various events. The current time is shown by a green
horizontal bar. It is possible to zoom in or out of this display to set the desired resolution, and to move
forward or backwards in time.
The diagrams and text boxes on the lower right quadrant display the spacecraft subsystem and payload
status (from telemetry data received from the spacecraft) and are defined by the user for the subsystems
and data to be displayed during the MOST setup and configuration. Included here is an antenna pattern
display showing the where the lines-of-sight to the ground stations are intercepting the antenna pattern.
Next to this is a nodal situational awareness display to show the relative position of other nodes (such as
other satellites in the constellation).
Figure 2. MOST main display with simulated satellite data
5 of 15
American Institute of Aeronautics and Astronautics

On the lower left are two strip chart displays which allow the user to select any telemetry parameters to be
displayed as a time history strip chart. The number of charts, time scale and parameter range of the strip
charts are user-definable. The user can also move backwards in time to view additional history.
The two 3D view windows show the satellite position with respect to Earth and its attitude with the values
of the essential orbital and attitude parameters. The attitude display shows vectors, such as the nadir,
velocity, and sun vectors. Both of these displays can be modified by the user to show different perspectives
and other viewing options.
A Caution and Warnings (C&W) Panel on top contains colored push buttons which are indicators for various
subsystems. These status lights (green, amber, red) are based on the limits testing that MOST does on input
telemetry.
MOST has several different modes of operation, as shown on the upper right side of the display. The modes
are:
• Real-Time (R/T) – which is really a “Near Real-Time” mode during which MOST displays streaming
data from a spacecraft during a contact with a ground station and passed through the ground network to
the Mission Operations Center (MOC). These data are the real-time data and not the stored data being
down-linked from the spacecraft. Once contact with the spacecraft is lost, the last values received continue to
be displayed, but MOST dulls the visual output to indicate that the values are not currently being updated.
This mode is used to support real-time operations.
• Extrapolated – MOST has the ability to take the latest real-time data and extrapolate them into the
future so that the user can see probable conditions of the spacecraft at some future time. MOST uses either
simple extrapolation techniques for independent variables such as time, or uses the models in the spacecraft
simulator to calculate values. Not all variables may be available in Extrapolated mode – it depends on
the implementation and how comprehensive the simulation models are. This mode can be used to support
mission planning, real-time operations or for simulations, training, analysis, etc.
• Simulated – This mode indicates that the data being displayed by MOST are simulated data being re-
ceived from the OTB/simulators. In all other ways (depending on the MOST settings) MOST behaves as if
these are real-time data. This mode is used when testing command scripts as part of the mission planning
process, and is also used for training, rehearsals, and looking at hypothetical cases during anomaly resolution.
• Archival – In this mode MOST reads in stored spacecraft data rather than real-time data. MOST allows a
user to scan back through archived data, and present the data at a speed that the user chooses. This mode
is most important for supporting analysis and trending of SOH or payload data, anomaly resolution, and
may also be helpful in certain circumstances for mission planning.
MOST actually consists of two software programs – the MOST Engine and the MOST User Interface. When
there are multiple spacecraft (or vehicular nodes), each one is assigned a dedicated MOST Engine that
accepts and processes the telemetry from the node and makes the data available to any tools operating
within COSMOS. This allows multiple sessions of MOST (i.e., MOST User Interface) to be looking at the
same spacecraft without each having to do the same processing as the other sessions. This also allows for the
data to be simultaneously used by the CEO (see following subsection). This architecture and methodology
used within COSMOS is discussed in more detail in the next section.
2. COSMOS Executive Operator (CEO)
While MOST concentrates on a single vehicle, with some indication of the surrounding context, such as
other satellites nodes, CEO is responsible for the larger context, refer to Figure 3. It monitors all Nodes in
a given sphere of operations, displaying a summary of their states of health, and providing access to their
various tools (such as MOST, and other COSMOS Tools for more unique Nodes.) Through a combination
of CEO and MOST, a complete picture can be derived of the current state of a fleet of vehicles.
6 of 15
American Institute of Aeronautics and Astronautics

5
The central pieces of this architecture, which is developed mostly in the object-oriented C++
programming language, are the visualization tools, support tools, and underlying programs that
produce and manipulate the data needed by the rest of the tool sets. It combines both the software
and unique hardware needed to support mission operations, including an operations test bed
(OTB) and simulators. The simulators are all software applications and the OTB combines
simulators with spacecraft hardware and test equipment where possible to mimic as closely as
possible the reaction of the spacecraft to commands and operational states in a realistic
environment. COSMOS was designed from the beginning to monitor and control multiple
satellites (up to at least 100) and keeping track of so many satellites is a difficult logistics and
human factors problem that is greatly helped by the COSMOS Executive Operator (CEO), a
prototype screen of which is shown in Figure 1. This will be a primary tool in this project.
Figure 1 - Mockup of the COSMOS Executive Operator (CEO). This shows a mission
simulation with 16 satellites in cooperative motion. The CEO overviews the whole set of satellites
and can control either the whole set or by bringing MOST up it can control individual satellites.
This software can be used in simulation and mission operations mode.
The basic philosophy behind the construction of the COSMOS architecture is that its elements
(tools and other programs) will be easy to port to a new location and to modify for operating with
new satellites. Beingan“openarchitecture”enables this capability. This approach means not only
that the source code of its major elements and structure are available, but also that it is designed to
accept external modules (which may not have source code available) as plug-ins through standard,
LocalT
MET
Orbit
14:43:07
1234:09:32:27
17126
Sat# Satel liteName MOST GSC
001 Ti nySat-1 Autonomous
002 Ti nySat-2 Autonomous
003 Ti nySat-3 Autonomous
004 Ti nySat-4 Autonomous
005 Ti nySat-5 Autonomous
006 Ti nySat-6 Autonomous
007 Ti nySat-7 Autonomous
008 Ti nySat-8 Autonomous
009 Ti kiSat- 1 Autonomous
010 Ti kiSat- 2 Autonomous Autonomous
011 Hawai iSat- 1 Autonomous
012 Hawai iSat- 2 S p aceCadet 1 SpaceCadet1
013 MightySat Manual
014 Cl earSat SpaceCade t2 SpaceCade t2
015 KUD0Sat-1 Autonomous
016 KUD0Sat-2 Autonomous
017 Box Sat-1 Autonomous
018 Box Sat-2 Autonomous
019 Box Sat-3 Autonomous
020 Box Sat-4 Autonomous
021 Box Sat-6 Autonomous
022 Box Sat-9 SpaceCadet3 Autonomous
023 Box Sat-10 Autonomous
024 Box Sat-11 SpaceCadet3 SpaceCadet3
025 SimSat-A SpaceCadet4 Manual
Controller Status MP ST MOST GSCT DMT TBCT CEO
FlightDirector On 1 1
SpaceCadet1 On 1 1
SpaceCadet2 On 1
SpaceCadet3 On 2 1
SpaceCadet4 Off
SpaceCadet5 Off
SpaceCadet6 Off
SpaceCadet7 Off
SpaceCadet8 Sim 1
SpaceCadet9 Off
SpaceCadet10 Off
Trainee1 Sim 1
Trainee2 On 1
Trainee3 On 1
Trainee4 Off
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
LOG
CONTROLALLOCATIONS
PERSONNEL
001
•
S
C
P
Actual
S
C
P
002
003
004 005
006
007
008
009 010
011 012
013
014
015
016
017
018
019
020
021 022
023
024
025
026
027
028
029
030
031 032
033
034
035
036
037
038
039
040
041 042
043
044
045
046
047
048
049
050
051 052
053
054
055
056
057
058
059
060
061 062
063
064
065
066
067
068
069
070
071 072
073
074
075
076
077
078
079
080
081 082
083
084
085
086
087
088
089
090
091 092
093
094
095
096
097
098
099
100
Sim
Actual Actual
Sim
C
S P
Actual
Actual
Actual Actual
Actual
Actual
Actual
Actual
C S P
C S
P
C S
P
C S P
C
S
P C
S P
C
S
P C
S
P
Actual Actual Actual A ctual
Actual Actual
Actual Actual Actu al A ctual Actual Actual Actual
S
C
P
S
C
P
S
C
P
C
S
P
C
S
P
C
S
P
S
C
P
SC
P C
S
P
C
S
P
C
S
P
C
S
P
S
C
P
•
•
•
•
UTC
MOC
2012-01-23 19:43:07
08:43:07
MSG
NODE#1(MC1)
STATUS
C E O
COSMOS
Executive
Operator
Lat 043.4N Long 090.6E Alt0123k
Lat 033.6N Long 007.4E Alt0489k
Sub-SatView
Actual
Simulation
Actual
Actual
Actual
OrbitView
Daylight
45:03 Umbra
GroundSt
22:10 AOSASF-1
B
L
C
LocalTime
245:19:07:58
ADCSMode
NominalS/CState
LVLH
EPS OBC ADC
RF
+
TCS
Daylight
26:58 Daylight
GroundSt
08:15 LOS
UHF,SBand
SSC
L
LocalTime
245:02:07:58
ADCSMode
NominalS/CState
IH2
EPS
C
B
OBC
ADC
RCSRF
+
OrbitView
Lat 0 73.6S Long 187.4E Alt0557k
Daylight
07:53 Umbra
GroundSt
17:20 AOS
KCC
LocalTime
245:07:07:58
ADCSMode
S/CState
LVLH
EPS OBC
ADC
RF
+
CONTACT
TCS
Nominal
Sub-SatView
Lat 0 33.6S Long 096.4E Alt0623k
Daylight
27:53 Daylight
GroundSt
37:20 AOS
KCC
LocalTime
245:09:0 7:58
ADCSMode
S/CState
SAFE
EPS OBC
ADC
RF
TCS
CAR
LCK
+
SAFE
Daylight
82:53 Umbra
GroundSt 17:20 LOS
VHF,SBand
SCC
LocalTime
245:21:07:58
OBC
ADC COM
TCS
B
C L
EPS
RCS
SM GNC
CM1
CM2
Lat 013.6N Long 196.4E Alt7623k
OrbitView
Actual
Actual
OrbitView
11
HawaiiSat-1
MOST
12
HawaiiSat-2
MOST
13
MightySat
MOST
14
ClearSat
MOST
15
KUDOSat-1
MOST
16
KUDOSat-2
MOST
Lat 0 88.6N Long 196.4E Alt5523k
Daylight
82:53 Umbra
GroundSt
17:20 LOS
VHF,SBand
SCC
LocalTime
245:21:07:58
OBC
ADC COM
TCS
B
C L
EPS
RCS
SM GNC
CM1
CM2
Lat 043.4N Long 090.6E Alt0123k
Lat 0 33.6N Long 007.4E Alt0489k
Daylight
45:03 Umbra
GroundSt
22:10 AOS
ASF-1
B
L
C
LocalTime
245:19:0 7:58
ADCSMode
NominalS/CState
LVLH
EPS OBC
ADC
RF
+
TCS
Daylight
26:58 Daylight
GroundSt
08:15 LOS
UHF,SBand
SSC
L
LocalTime
245:02:07:58
ADCSMode
NominalS/CState
IH2
EPS
CB
OBC
ADC
RCS
RF
+
Lat 073.6S Long 187.4E Alt0557k
Daylight
07:53 Umbra
GroundSt
17:20 AOS
KCC
LocalTime
245:07:07:58
ADCSMode
S/CState
LVLH
EPS OBC ADC
RF
+
CONTACT
TCS
Nominal
Lat 033.6S Long 096.4E Alt0623k
Daylight
27:53 Daylig ht
GroundSt
37:20 AOS
KCC
LocalTime
245:09:0 7:58
ADCSMode
S/CState
SAFE
EPS OBC
ADC RF
TCS
CAR
LCK
+
SAFE
OrbitView
Sub-SatView
Sub-SatView
Sub-SatView
Sub-SatView
Sub-SatView
Actual
Actual
Actual
Actual
21
BoxSat-6
MOST
22
BoxSat-9
MOST
23
BoxSat-10
MOST
24
BoxSat-11
MOST
25
SimSat-1
MOST
26
SimSat-2
MOST
17
BoxSat-1
MOST
18
BoxSat-2
MOST
19
BoxSat-3
MOST
20
BoxSat-4
MOST
Actual
Actual
Actual
Actual Simulation
Sub-SatView OrbitView
Lat 023.4S Long 090.6E Alt0123k Lat 043.4N Long 090.6E Alt0123k Lat 043.4S Long 090.6E Alt0123k
Lat 043.4S Long 090.6E Alt0123k
Lat 043.4S Long 090.6E Alt1123k
Lat 0 43.4S Long 090.6E Alt0723k
OrbitView
OrbitView
Daylight
45:03 Umbra
GroundSt
22:10 AOS
ASF-1
B
L
C
LocalTime
245:19:07:58
ADCSMode
NominalS/CState
LVLH
EPS OBC
ADC
RF
+
TCS
Daylight
26:58 Daylight
GroundSt
08:15 LOS
UHF,SBand
SSC
L
LocalTime
245:02:07:58
ADCSMode
NominalS/CState
IH2
EPS
C
B
OBC
ADC
RCS
RF
+
Daylight
07:53 Umbra
GroundSt
17:20 AOS
KCC
LocalTime
245:07:07 :58
ADCSMode
S/CState
LVLH
EPS OBC ADC
RF
+
CONTACT
TCS
Nominal
Daylight
27:53 Daylight
GroundSt
37:20 AOS
KCC
LocalTime
245:09:07 :58
ADCSMode
S/CState
SAFE
EPS
OBC
ADC RF
TCS
CAR
LCK
+
SAFE
Daylight
07:53 Umbra
GroundSt
17:20 AOS
KCC
LocalTime
245:07:07:58
ADCSMode
S/CState
LVLH
EPS OBC
ADC
RF
+
CONTACT
TCS
Nominal
Daylight
07:53 Umbra
GroundSt
17:20 AOS
KCC
LocalTime
245:07:07:58
ADCSMode
S/CState
LVLH
EPS OBC
ADC
RF
+
CONTACT
TCS
Nominal
SORT
SELECT
GroundSt
KCC
245:07:07:58
LocalTm
Azimuth
Elevation
MaxElev
AOS
LOS
82.4
009
Sat#
281.3
19:38:37[+05:30]
67.5-
19:47:27 [-04:20]
UHF
Band
CONTACT
AUTO
Mode
KCC
ASF-1
ASF-2
SCC-1
SCC-2
ABC DEF-1
DEF-2
DEF-3
GHI-2
HMC3-1
HMC3-2
NMC3-1
NMC3-2
SMC3-1
SMC3-2
BMC3-1
BMC3-2
WPGS
ARC-1
ARC-2 ARC-3
ARC-4
ARC-5
OPER STBY
OPER
DOWN
STBY
LNK
STBY OFFOPER OPER
STBY OPER STBY STBY
OFF
OFF
OPER
OPER LNK
DOWN
OPER
OPER
STBY
OPER
UHF
S-B
S-B
UHF
S-B
C-B
S-B
S-B
X-B
Ku-B
UHF
S-B
UHF
S-B
UHF
S-B UHF
S-B
UHF
UHF
VHF
UHF
S-B
S-B
#1 #2 #3 #4 #5 #6 #7 #8 #9 #10
10%
CPU
MEM
DISK
MC1
MC2
MC3
OTB1 OTB2 MC5
MC6
MC7 MC8
MC9
Figure 3. The COSMOS Executive Operator (CEO). This shows a mission simulation with 16 satellites in
non-cooperative motion. The CEO overviews the whole set of satellites and can control either the whole set or
by bringing MOST up it can control individual satellites. This software can be used in simulation and mission
operations mode.
7 of 15
American Institute of Aeronautics and Astronautics

The major components of the CEO are presented upon two interfaces, the main CEO window and the flight
dynamics window. These two seperate interfaces. In the background, a thread is started when the program
is initiated. This thread will monitor all broadcast messages on the network and parse them to proper data
structures which are then used for continual monitoring and updating of the CEO graphical user interfaces.
The CEO Main Window consists of the following components:
• UTC and MOC local time fields.
• A mercator map projection (2D) of the earth used to display ground stations and their and satellites
and their tracks.
• A list box of nodes that are being monitored by the CEO. A node number, a node name, and the type
of node are presented for each node found.
• A list box of users, their machine, and the tools that they are using. This box in the future will provide
the capability of sending a message to that user by broadcasting to the tool that they are currently
using.
• Orbital views of satellite nodes being monitored. Each view contains the 3D display which offers the
same views as that of the orbit window in MOST. These views are selected by clicking on the view type
of the dropdown widget located in the upper right of the box. Fields for latitude, longitude, altitude,
UTC and local time, satellite state and ADCS state are located below the 3D display.
In addition, two progress bars are shown. The Umbra/Daylight bar will show how long the satellite has
been its current state of either umbra or daylight and how long until it exits that state. The LOS/AOS
bar shows how long its been in either LOS or AOS and how long it exits that state. To the right of
that bar is the ground station for either the AOS that it currently is in or will enter.
A user wishing more detailed information can initiate a MOST session focusing on that node by clicking
the MOST button at the top center portion of the box.
• Text boxes for ground station information. Information presented includes the UTC and local time for
the ground station and the elevation and azimuth of the antenna at the ground station.
• A button to kick off the flight dynamics window is located at top right location of the CEO main
window. The flight dynamics window is discussed in the following section.
The current working configuration of CEO allows for the simultaneous monitoring of up to eight satellite
nodes and three ground station nodes. This configuration was selected to test COSMOS (in shadow mode)
with the upcoming NASA EDSN mission, which consists of eight CubeSats in a formation flying demon-
stration. However, CEO has been designed to monitor up to 100 satellites (or similar vehicle nodes) and 30
ground station (antenna) nodes.
Flight Dynamics Window
This window is nearly identical to that which is contained within the MOST program. The information
contained within the flight dynamics window is based with respect to a central node and its specified targets
in the node.ini file for that specific node. At the top right of the flight dynamics interface is a Central Node
dropdown box. This allows for the user to change the focus from one node to another. All subsequent dis-
plays on the flight dynamics windows will then update with the new central node and its targets comprising
the information displayed in the various windows and displays.
Using the COSMOS framework we have many of the tools for designing, modeling, and visualizing the
performance of multiple vehicles in an iGNC environment. The following sections will describe the rendezvous
problem and show some of the results obtained using COSMOS.
8 of 15
American Institute of Aeronautics and Astronautics

III. Rendezvous Problem Formulation
Consider two Low Earth Orbiting spacecrafts (interceptor-satellite and target-satellite) that need to move
to a desired relative position by minimizing the fuel consumption and by making a soft approach (velocity
is zero at the desired target point). The interceptor-satellite is in the vicinity of the target-spacecraft for
simplicity. We assume the use of GPS sensors to provide the position and velocity information of the inter-
ceptor and target spacecrafts. We also assume that the target-spacecraft can inform the interceptor of its
current position.
The following are the assumptions that are applied to the solution of this rendezvous problem:
• trajectory control is 3-dimensional
• realistic relative motion formulation using Hill’s equations
• GPS sensor for relative state information
• E-guidance for trajectory planning
• State vector is : x = [x, y, z, ˙x, ˙y, ˙z]
Relative Formation dynamics is used to formulate the motion of a reference satellite in Low Earth Or-
bit (LEO). An orbital frame centered in the satellite that is pointing to the Earth (Local-Vertical Local-
Horizontal) is used. The radial direction pointing toward the Earth determines the ~x-axis, the ~z-axis points
towards the direction of the angular momentum vector and the ~y-axis is determined by the cross product of
~z × ~x.
The Clohessy-Wiltshire equations, also known as the Hill’s equations, describe the relative motion of satellites
with respect to a reference satellite, the target-satellite in this case. The Hill’s equations take the form:
¨x − 2ω ˙y − 3ω
2
x = u
x
¨y + 2ω ˙x = u
y
(1)
¨z − ω
2
z = u
z
where x, y, z is the relative position of the non-reference satellite with respect to the reference satellite, and
u
x
, u
y
, u
z
are the control inputs.
For LEO orbits the relative motion is affected by the Earth’s oblateness factor (J2) and atmospheric drag
but for short periods of time these assumptions can be ignored to simplify the mathematical formulation.
The analytical solution to Hill’s equations is known for circular orbits without these effects:
8
x(t) =

2 ˙y
0
ω
− 3x
0

cos(ωt) +
˙x
0
ω
sin(ωt) +

4x
0
−
2 ˙y
0
ω

+
2
ω
2
u
y
(sin(ωt) − ωt) +
u
x
ω
2
(1 − cos(ωt))
y(t) =

4 ˙y
0
ω
− 6x
0

sin(ωt) −
2 ˙x
0
ω
cos(ωt) + (6ωx
0
− 3 ˙y
0
) t (2)
+

y
0
+
2 ˙x
0
ω

+
2
ω
2
u
x
(ωt − sin(ωt)) + u
y

4
ω
2
(1 − cos(ωt)) −
3
2
t
2

z(t) =z
0
cos(ωt) +
˙z
0
ω
sin(ωt) +
u
z
ω
2
(1 − cos(ωt))
The discrete state-transition matrix based of the Hill’s equations is used to obtain the solution of the
linearized dynamical system of the interceptor satellite.
9 of 15
American Institute of Aeronautics and Astronautics

A =










1 0 0 ∆t 0 0
0 1 0 0 ∆t 0
0 0 1 0 0 ∆t
3ω
2
∆t 0 0 1 0 0
0 0 0 −2ω∆t 1 0
0 0 −ω
2
∆t 0 0 1










, B =










0 0 0
0 0 0
0 0 0
1 0 0
0 1 0
0 0 1










The linearized state propagation is given by:
x
k+1
= Ax
k
+ Bu
k
(3)
IV. Integrated Guidance, Navigation and Control (iGNC) Framework
The addition of an iGNC framework to COSMOS is the underlaying architecture for realistic coordination
and motion control of multiple small spacecraft. The iGNC technology unifies relative navigation solutions
and real-time guidance concepts into the COSMOS framework. The GNC principles are employed to each
spacecraft with a modular approach for better integration of these GNC functions into multiple small satel-
lites independently of their relative motion such as formation flying, proximity operations, rendezvous and
docking. Figure 4 shows the iGNC diagram of the software implemented within COSMOS.
Guidance
u
g
(k),u
g
(k+1)
Navigation
Navigation
Sensor Fusion
State Estimation
X(x,v,a,q) – state vector
Control
u=u(x)
Sensors
Actuators
Dynamics
External
Disturbances
iGNC On Board Computer Software Vehicle
Agent driver
COSMOS Node Software Agent
COSMOS
Data Packets
Figure 4. integrated Guidance, Navigation and Control diagram within the COSMOS Node.
A. Guidance
Two different guidance laws were experimented in this work: PD-guidance and E-Guidance. PD-guidance
refers to a simple Proportional-Derivative guidance control scheme for the rendezvous maneuver. The PD-
guidance command takes the form:
u
i
(t) = K
p
e
i
(t) + K
d
d
dt
e
i
(t), for i = 1, 2, 3 (4)
Proportional-Derivative control can be used when steady-state error is null. The Proportional action pro-
vides an fast response to the control error. Derivative action acts on the rate of change of the control error,
in this case it’s the velocity difference between the target and interceptor. This provides a faster response
10 of 15
American Institute of Aeronautics and Astronautics

to the controller and a smoother approach.
E-guidance is an explicit method for optimizing thrust vehicles guidance commands given initial and final
conditions (boundary value problem). This method was originally developed for the Apollo Guidance and
Navigation as an explicit optimizing method
9
but it is now adapted for spacecraft rendezvous. Part of the
E-guidance scheme is the E-matrix that relates the desired final state with the current state. This in turn
creates a type of proportional-derivative mechanism to compute the guidance coefficients for efficient ma-
neuvering of spacecraft.
The E-guidance formulation for this particular problem is expressed by the E-Matrix and P-vector.
E =
"
4.0/T
g o
−6.0/T
2
g o
−6.0/T
2
g o
12.0/T
3
g o
#
P
i
=
"
˙x
d
i
− ˙x
i
x
d
i
− (x
i
+ ˙x
i
T
g o
)
#
C
x
i
,y
i
,z
i
= EP
i
, i = 1, 2
u
x
= (C
x
1
p
1
+ C
x
2
p
2
) − 2ω ˙y − 3ω
2
x (5)
u
y
= (C
y
1
p
1
+ C
y
2
p
2
) − 2ω ˙x (6)
u
z
= (C
z
1
p
1
+ C
z
2
p
2
) + ω
2
˙x (7)
The acceleration factor in this problem is changed from the original formulation of the E-guidance described
in.
9
This is because the reference frame is changed and there are fictitious forces that must be accounted
for in the Hill’s frame to maintain the right form.
B. Control
After the current state of the satellite is estimated it is necessary to compute the automated maneuver to
approach the desired state in a optimal way. Using Linear Quadratic Regulator (LQR) is one way of doing
this because it defines an optimal feedback control for a linear system as the Hill’s equations for the simplified
case are. From the state space model
˙
X = AX(t) + Bu(t) (8)
Y = CX(t) + Du(t) (9)
and for the continuous case
A =










1 0 0 1 0 0
0 1 0 0 1 0
0 0 1 0 0 1
3ω
2
0 0 1 0 0
0 0 0 −2ω 1 0
0 0 −ω
2
0 0 1










, B =










0 0 0
0 0 0
0 0 0
1 0 0
0 1 0
0 0 1










C = I
6,6
, D = 0
A quadratic cost function is defined to be
J =
1
2
Z
inf
0

X
T
e
QX
e
+ u
T
Ru + 2u
T
NX
e

dt (10)
11 of 15
American Institute of Aeronautics and Astronautics

where X
e
is the tracking error. The algebraic Ricatti equation can be solved to find the solution to this
optimal problem: u
optimal
.
u(t) = −K
LQR
(X(t) − X
desired
) (11)
By having u we can determine the final time at which the interceptor gets into the desired state T that is
then plugged into the guidance equations.
In the case of this project the interest is to minimize the fuel or energy expenditure, and not so much the
time. Using the cost representing energy spending we have:
J = min
u
0
,...,u
k−1
k−1
X
i=0
ku
i
k
where u
i
is the acceleration to be applied to the spacecraft in each i-axis.
V. Simulations
The simulations of the problem presented have been implemented within the COSMOS agents and current
progress is being made to implement the fully integrated simulations with the COSMOS Graphic Tools. The
following paragraphs summarize the main results of this particular rendezvous solution using the COSMOS
framework. These results provide a notion on how E-guidance performs in comparison to a the PD-guidance
law.
Figure 5 shows the state position (~x) of the interceptor spacecraft. It shows the simulated states with no
control input to show how the spacecraft would drift if nothing would be done. It also shows the estimated
state of the position for a smooth approach using the information given in the problem statement. It also
shows the sensor data collected that enables the execution of the Extended Kalman Filter. The red and
green lines show the difference between the PD-guidance and the E-guidance. It’s clear that the oscillatory
movement from the PD-guidance makes the spacecraft spend more energy.
Figure 6 shows the state velocity (
~
˙x) of the interceptor spacecraft. It shows the performance of the estimated
velocity during rendezvous computed by the discrete Extended Kalman Filter. Similarly to the previous plot
it compares the PD-guidance with the E-guidance. Again, this plot shows a typical oscillatory movement
for the PD-guidance which differs quite significantly from the E-guidance.
Figure 7 compares the performance of the guidance laws:
• plot 1: shows the instantaneous cost (J) at each given time for the two guidance schemes. The PD-
guidance is very much exausted, also the scale on the right hand side (that corresponds to the the
PD-guidance) shows much higher values than the E-guidance scale.
• plot 2: m spacecraf mass during rendezvous maneuver. The mass is computed by the given model for
thrust force. It is not part of the computed states in the Extended Kalman filter because it is directly
related to the computed states and also because there is no measurement made of the spacecraft mass.
It’s important to nocite how the mass on the green line (E-guidance) does not move much meaning
that there is low fuel expenditure.
• plot 3: this plot shows the distance between the target position and the interceptor spacecraft for the
two guidance laws. It’s noticeable that the E-guidance takes the full time to reach the goal but in this
way it is able to significantly save fuel.
• plot 4: β is the mass flow. Notice the scale difference and how the PD-guidance is consistent with the
plots above since there is a significant higher flow rate than the E-guidance.
12 of 15
American Institute of Aeronautics and Astronautics

Figure 5. Position for simulated soft rendezvous with target satellite using E-guidance on interceptor
Figure 6. Velocity for simulated soft rendezvous with target satelltie using E-guidance on interceptor
13 of 15
American Institute of Aeronautics and Astronautics

Figure 7. Performance of rendezvous maneuver. (1) Cost performance and comparison between PD-guidance
and E-guidance. (2) Mass performance for the two guidance schemes. (3) Absolute distance. (4) β or fuel flow
rate
VI. Conclusion
The COSMOS system is being developed by HSFL and is designed specifically to make the design, planning,
monitoring, and control of multiple small satellites missions more manageable. By designing COSMOS with
an open-architecture philosophy, the operations system will become more readily available for use, especially
by universities, and is expected to sprout a development community that will soon increase its capabilities.
This work presents the expansion of the COSMOS software to control multiple satellites with an integrated
Guidance, Navigation and Control (iGNC) framework. A case study is presented to control the rendezvous of
two satellites in real time. This new software framework permits the creation of new simulation scenarios for
autonomous formation flying, rendezvous and docking, and proximity operations. This work also facilitates
the development of flight software for missions involving multiple small spacecraft, thereby reducing the cost
of mission design and pre-mission simulations, and increasing the software reliability. We also show that this
software framework can be used for research on novel control and estimation methods for satellite trajectory
and attitude. We introduce a new guidance law (E-guidance) for rendezvous of two spacecraft and show
that it is more efficient compared to a typical Proportional-Derivative guidance law. Further work is being
developed to expand the COSMOS framework to use more than two satellites in this type of scenario and
also to experiment with other iGNC schemes to include attitude control for realistic six degrees of freedom
maneuvers.
14 of 15
American Institute of Aeronautics and Astronautics

References
1
Trevor C. Sorensen, Carol V. Hude, Marcelo H. Kobayashi, Eric J. Pilger, Amit K. Sanyal, Lance K. Yoneshige, and Miguel A.
Nunes. LEO-1: Development of a University Microsatellite For Flight Testing New Technologies. AIAA Space Conference
#2009-6812, 2009. Cleared for public release by ORS/DoD, 2009.
2
Miguel A. Nunes. Satellite Constellation Optimization Method for Future Earth Observation Missions Using Small Satellites.
Advances in the Astronautical Sciences, 146:159–179, 2013.
3
Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, Miguel A. Nunes, and Lance K. Yoneshige. Mission design and operations
of a constellation of small satellites for remote sensing. In Khanh D. Pham, Joseph L. Cox, Richard T. Howard, and Genshe
Chen, editors, SPIE 8739, Sensors and Systems for Space Applications VI, 873906 (May 21, 2013), pages 873906–873906–17,
May 2013.
4
Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, Miguel A. Nunes, and Bruce D. Yost. Development of a Comprehensive
Mission Operations System Designed to Operate Multiple Small Satellites. In AIAA/USU Small Satellite Conference, Logan,
UT. #SC11-IX-3, 2011.
5
Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, Miguel A. Nunes, Harold M. Garbeil, Erik K. Wessel, and Wes Jamroz.
Adapting an Open-architecture mission Operations System for a Lunar Rover Mission. In 63rd International Astronautical
Congress, Naples, Italy, 2012.
6
Trevor C. Sorensen, Eric J. Pilger, Mark S. Wood, and Miguel A. Nunes. A University-developed Comprehensive Open-
architecture Space Mission Operations System (COSMOS) to Operate Multiple Space Vehicles. Paper selected for the post-
conference book ”Space Operations: Experience, Mission Systems & Advanced Concepts - AIAA 2013”. In Space Ops Conference
2012. Cleared for public release by NASA Ames, 2012.
7
T. C. Sorensen, T. T. Tran, B. J. Geldzahler, D. M. Horan, and R. J. Prescott. Effective Science Mission Planning and
Operations - The Clementine Approach. In Proc. RAL.GS.31, 1st Annual Reducing the Cost of Space Ground Systems and
Operations Symposium, Rutherford-Appleton Laboratories., 1995.
8
Wigbert Fehse. Automated Rendezvous and Docking of Spacecraft. Cambridge University Press, Cambridge, 2003.
9
George W. Cherry. E Guidance - A General Explicit, Optimizing Guidance Law for Rocket-Propelled Spacecraft, Apollo
Guidance and Navigation. Technical report, MIT Instrumentation Lab, 1964.
15 of 15
American Institute of Aeronautics and Astronautics