On the development of a 6DoF GNC framework for docking multiple small satellites Miguel A. Nunes∗, Trevor C. Sorensen†, Eric J. Pilger‡ University of Hawaii at Manoa, Hawaii Space Flight Laboratory, Honolulu, HI, 96822, USA
Small and very capable satellites are becoming an attractive option for future space missions by reducing the cost, decreasing the risk and improving flexibility. Small satellites can also be used as building blocks of large space structures such as solar panels or space telescopes. This work is focused on the development of a position and attitude GNC framework for docking multiple small satellites in a cooperative manner using the Comprehensive Open-architecture Solution for Mission Operations Systems (COSMOS) developed at the Hawaii Space Flight Laboratory. We introduce a 6DoF guidance law for position and attitude that optimizes fuel consumption and use the COSMOS software agents to bundle individual satellite dynamics for a realistic simulation. By using the COSMOS agents each satellite can broadcast its information to the network making it available to all other satellites. An important outcome of this work is the development of the flight-like software that can be used in real time simulation environments and for mission rehearsals.
I.
Introduction
The first docking of two spacecraft was performed in 1966 during the Gemini program in preparation for the lunar missions,1 and was human controlled. Gemini 8 was commanded by Neil Armstrong while he docked the spacecraft with the unmanned Agena Target Vehicle. The first fully automated docking between two spacecraft was just the year after in 1967 by two Soviet spacecraft: Kosmos 186 and Kosmos 188. Since then there have been other successful examples of docking missions, but they mostly fall in the category of large spacecraft and human space exploration such as ESA’s Automated Transfer Vehicle. Just recently interest has increased on the prospects of autonomously docking small satellites. One of the most advanced concepts is the newly proposed technology demonstration missions such as the Cubesat Proximity Operations Demonstration (CPOD),2 this is a step towards future missions that can utilized multiple small satellites. The CPOD mission is the first that will demonstrate rendezvous, proximity operations and docking using two cubesats, expected to launch in 2015. The Autonomous Assembly of a Reconfigurable Space Telescope (AAReST) is another mission concept that has been proposed3 with the use of multiple cubesats. With the ongoing effort to reduce the cost of small satellites and increase their capabilities, the expectations of new space missions are also increasing. One particular avenue is using multiple satellites to develop modular space assets such as large space telescopes, solar arrays, satellite servicing stations, etc. Our work is focused on creating a GNC framework that may enable the docking of multiple cubesats, this is the foundational work to enable realistic simulation scenarios for future mission designs and analysis using multiple satellites. In this paper we simulate the docking of 4 cubesats as it is conceptually represented in Fig. 1. The Hawaii Space Flight Laboratory (HSFL) at the University of Hawaii at Manoa is developing the capabilities to design, build, and operate small satellites within the paradigm of cost reduction.4 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 ∗ Ph.D. Candidate - Research Assistant, Hawaii Space Flight Laboratory, 1680 East-West Rd. POST 501, Honolulu, HI, 96822, AIAA Student Member. Email:
[email protected] † 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.
1 of 13 American Institute of Aeronautics and Astronautics
also been involved in multiple studies for the use of satellite constellations for Earth Observations. We have developed optimization methods for satellite constellations5 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.6 These methods are enabling the study of space missions that have not yet been proposed before because of technological limitations or proper analysis formulations. It is within this context that some research is being done in the use of multiple small satellites and in particular, the docking of multiple cubesats.
©Ma r a Br a n c o . c o m
Figure 1. Docking 4 cubesats concept
We have also been developing the Comprehensive Open-architecture Solution for Mission Operations Systems (COSMOS). COSMOS is intended to be a unified framework for mission operations, not only for the ground operations, but also at the satellite level.7 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 missions76 , for rover missions,8 and more recently we started looking into the operations of multiple satellites.9 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. One of the critical aspects of rendezvous and docking missions is the minimization of energy expenditure. 2 of 13 American Institute of Aeronautics and Astronautics
Other works have looked into this problem. Kobilarov10 expands on a maneuver mechanism using a crossentropy motion planning method that searches for the optimal trajectories. Phillips11 develops a 6DoF rendezvous and docking method with a gradient descent approach using impulsive control. McCamish12 uses a distributed control approach based on the LQR and a potential function method for collision avoidance. In this paper we propose a optimal guidance method based on the E-guidance schemes. 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 and docking of multiple satellites. This rendezvous simulation is based on an integrated Guidance, Navigation and Control framework that is incorporated into the COSMOS software.
II.
C++11 for simulation and visualization
For this project we decided to use C++11 for the development of a GNC framework and the simulation of docking the cubesats. We have considered the use of other modern programming languages such as Python, but none other was as flexible, compatible and stable as C++. With C++ we can reuse other libraries developed by the Hawaii Space Flight Laboratory for the COSMOS project and also use part of the simulation code and port it directly into the embedded processors for cubesats. It also gives us the flexibility to make the software work seamlessly in Linux, Mac OS and Windows. C++ is a very flexible object oriented programming language with optimal low level memory management manipulation features. It is one of the fastest programming languages and more complete in functional terms. Its abstraction capabilities make possible the creation of very systematic, organized and reusable code. C++ is designed with a bias for systems programming such as embedded systems, that in the case for this project where the target embedded system is a spacecraft processor. C++11 is the revision of the C++ programming language released in 2011. It replaced C++03 that is still prominent in the software development industry. The latest versions of modern compilers such as GCC, Clang and Intel C++ have full support for C++11, while others like MSVC have almost full support. Even embedded architectures using ARM processors are supporting the new modern C++ features. One of the major downsides of the C++ programming language that is usually refereed is the steep learning curve, nonetheless with the new C++11 standard and so many learning resources readily available the trend is changing in favor of this powerful programming language. One of the major problems when using C/C++ is that the mathematical frameworks for matrix operations and numerical integration is not easily available. While this is true at first glance, there are however some readily available C++ libraries that are peer reviewed, open source and free, fast and optimized. For this project we use Eigen for matrix operationsa . Eigen is an open source high-level C++ library mostly for linear algebra, matrix and vector operations. For numerical integration we use Odeintb , a modern C++ library for numerically solving Ordinary Differential Equations. With complex simulation scenarios it is important to be able to visualize the data generated and interact with it, with C++ we can directly access graphics libraries for visualization of the simulation data such as OpenGl and Qt. OpenGL is the Open Graphics Library, a multi-platform application programming interface (API) for rendering high performance 2D and 3D vector graphics. The OpenGl API interacts with a graphics processing unit (GPU), to achieve hardware-accelerated rendering making the visualization process independent of the simulation, leaving the main processor mostly for the simulation only. Qt is a cross-platform application framework used mostly for graphic window creation but also with extended functionality over many other Operating System functions. It has a user friendly API for OpenGl making a http://eigen.tuxfamily.org/ b http://headmyshoulder.github.io/odeint-v2/
3 of 13 American Institute of Aeronautics and Astronautics
readily available to use in any Qt application. Finally we use QCustomPlotc , that is a Qt/C++ based library for plotting and data visualization.
III.
COSMOS Framework
A cooperative system for docking multiple cubesats must be aware of the different vehicles (dynamic nodes) and it must be capable of sharing information and decide what to do with the incoming information autonomously. Reliable communication is critical to cooperation. In this project we are developing a system that communicates through active message passing, but passive observation would be another option. This is accomplished with the COSMOS agents that exist in each satellite and share the desired information within the unified framework. Each COSMOS agent contains the Guidance, Navigation and Control scheme that has been developed in this work and each agent responds to the information received from other agents. Because we assume each satellites is capable of physical motion, the main goal is to move each satellite to a desired position and attitude in a optimal way to achieve the desired configuration.
Figure 2. MOST main display with simulated cubesat data, mission events and telemetry data visualization. In the bottom it shows the nodal awareness widget that tracks the satellites that are closest to the monitored satellites.
COSMOS7, 9 is a suite of software and hardware tools that enables the Mission Operations Center to interface with the spacecraft, payloads and ground control network in order to perform the mission operations functions. This includes mission planning and scheduling, contact operations, data management and analysis, simulations with hardware in the loop, ground network control, payload operations and system management. COSMOS is being designed to be easily adapted for new spacecraft and easily be installed for new Mission Operations Centers. We have carefully designed COSMOS to be compatible with embedded hardware so that missions can take advantage of the seamless combination of software and hardware. That enables us to address all phases of the spacecraft life-cycle with a more integrated approach; from the design, development, testing, implementation, and up to 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 c http://www.qcustomplot.com/
4 of 13 American Institute of Aeronautics and Astronautics
from the lowest byte level through the coordination of multiple intercommunicating processes with a high level graphical user interface. It is 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 project 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 referred 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.
Figure 3. The COSMOS Executive Operator (CEO). This shows a mission simulation with 4 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.
COSMOS Agents are special persistent COSMOS aware programs that, through a special protocol defined for COSMOS, can file requests from other COSMOS aware programs. They are, by their nature, multithreaded. 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. The Mission Operations Support Tool (MOST), Fig. 2 is one of the primary COSMOS 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
5 of 13 American Institute of Aeronautics and Astronautics
to other vehicles and the ground. Any data variable in the COSMOS namespace can be configured to be displayed graphically. Particular 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. While MOST concentrates on a single vehicle, with some indication of the surrounding context, such as other satellites nodes, the COSMOS Executive Operator (CEO) is responsible for the larger context, refer to Fig. 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. For this particular project, of close proximity and docking of four satellites, we developed four COSMOS software agents, one for each satellite. Each agent simulates the dynamics and reports its state information to the network. Figure 4 shows a diagram of the COSMOS software implementation for this particular problem. We also developed a Ground Station Agent that receives and forwards the cluster dynamic state 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, MOST and CEO, to visualize and control the satellites.
COSMOS Agent #1
COSMOS Agent #2
External Disturbances
Guidance ug(k),ug(k+1)
External Disturbances
Guidance
Control
ug(k),ug(k+1)
u=u(x)
Control u=u(x)
Actuators Agent driver
Actuators Agent driver
Dynamics Navigation
GNC On Board Computer Software
Dynamics Navigation
Sensors
Sensor Fusion State Estimation X(x,v,a,q) – state vector
Sensor Fusion State Estimation X(x,v,a,q) – state vector
Vehicle Dynamics
GNC On Board Computer Software
Vehicle Dynamics
COSMOS Space network
COSMOS Space network
Sensors
COSMOS Space network
COSMOS Data Packets
COSMOS Agent #3 Guidance ug(k),ug(k+1)
COSMOS Agent #4
External Disturbances
Guidance
Control
ug(k),ug(k+1)
u=u(x)
Control u=u(x)
Actuators
Actuators Agent driver
Agent driver
Dynamics Navigation
Sensor Fusion State Estimation X(x,v,a,q) – state vector
GNC On Board Computer Software
External Disturbances
Dynamics Navigation
Sensors
Sensor Fusion State Estimation X(x,v,a,q) – state vector
GNC On Board Computer Software
Vehicle Dynamics
Sensors
Vehicle Dynamics
Figure 4. integrated Guidance, Navigation and Control diagram using COSMOS node architecture.
For this particular project we have developed the COSMOS 3D docking viewer program to help the mission designer visualize the docking maneuvers. Figure 5 and 6 show the docking viewer at two different stages of the docking sequence. This program allows the designer to run multiple simulations from given initial conditions and then replay the simulation in multiple ways, real time, faster than real time, reverse time or even with a slider. It is also possible to select which performance plots must appear of the right hand side of the program.
6 of 13 American Institute of Aeronautics and Astronautics
Figure 5. COSMOS 3D Docking Viewer with four cubesats at their initial configuration. The docking viewer shows the 3D maneuvers of each satellite and also shows the preselected performance plots on the right side. Each cubesat is drawn to the scale.
Figure 6. COSMOS 3D Docking Viewer with four cubesats at the end of the simulation. The docking viewer shows the 3D maneuvers of each satellite and also shows the preselected performance plots on the right side. Each cubesat is drawn to the scale.
7 of 13 American Institute of Aeronautics and Astronautics
IV.
Problem Formulation
We start by considering a simplified model for docking two Low Earth Orbiting (LEO) spacecraft (interceptorsatellite 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 interceptor and target spacecraft and also we assume, in this work, a perfect knowledge of the satellite attitude. We also assume that the spacecraft can broadcast their current position in real time (no delays) with the COSMOS agents. Each spacecraft is modeled as a fully actuated rigid body where the state vector is the combination of position x = [x, y, z] ∈ R3 , velocity x˙ = [x, ˙ y, ˙ z] ˙ ∈ R3 , attitude quaternion q = (r, ~v ) = [qr , (qx , qy , qz )] r ∈ R, ~v ∈ R3 , and the body fixed angular velocity ω = [ωx , ωy , ωz ] ∈ R3 . The satellite has the inertia tensor made of the principal moments of inertia J = diag(Jx , Jy , Jz ). The following are the assumptions applied to the solution of this rendezvous and docking problem: trajectory control is 6-dimensional, realistic relative motion formulation using Hill’s equations, GPS sensor for relative position information, the attitude information is assumed to be fully known and an adapted E-guidance method for trajectory and attitude planning. The state vector is [x, x, ˙ q, ω]. The actuation of the spacecraft has control inputs u ∈ U ⊂ R6 where for this work U is not yet bounded, f ∈ R3 are the translational forces and τ ∈ R3 are the torques acting on the satellite body. Relative Formation dynamics is used to formulate the motion of a reference satellite in Low Earth Orbit (LEO). An orbital frame centered in the satellite that is pointing to the Earth (Local-Vertical LocalHorizontal) 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 most important forces and torques experienced in LEO come the relative dynamics and the gravity gradient. The Clohessy-Wiltshire equations, also known as the Hill’s equations, describe the motion dynamics very accurately for near circular orbits. These model the relative motion of satellites with respect to a reference satellite, the target-satellite in this case. The Hill’s equations for the reference frame described above take the form: x ¨ − 2ωo y˙ − 3ωo2 x = ux y¨ + 2ωo x˙
= uy
ωo2 z
= uz
z¨ −
(1)
where x, y, z is the relative position of the satellite with respect to the reference satellite, and non-reference µEarth 2 > 0 is the orbital angular rate constant. ux , uy , uz are the control inputs, ωo = r3 sat
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:1
x˙0 2y˙0 2y˙0 − 3x0 cos(ωo t) + sin(ωo t) + 4x0 − x(t) = ωo ωo ωo 2 ux + 2 uy (sin(ωo t) − ωo t) + 2 (1 − cos(ωo t)) ω ωo o 4y˙0 2x˙0 y(t) = − 6x0 sin(ωo t) − cos(ωo t) + (6ωo x0 − 3y˙0 ) t ωo ωo 2x˙0 2 4 3 2 + y0 + + 2 ux (ωo t − sin(ωo t)) + uy (1 − cos(ωo t)) − t ωo ωo ωo2 2 z˙0 uz z(t) =z0 cos(ωo t) + sin(ωo t) + 2 (1 − cos(ωo t)) ωo ωo
8 of 13 American Institute of Aeronautics and Astronautics
(2)
The discrete state-transition matrix based of the Hill’s equations is used to linearized dynamical system of the interceptor satellite for x = [x, y, z, x, ˙ y, ˙ z]. ˙ 0 1 0 0 ∆t 0 0 0 0 1 0 0 ∆t 0 0 0 0 1 0 0 ∆t ,B = A= 1 2 0 1 0 0 3ωo ∆t 0 0 0 0 0 −2ωo ∆t 1 0 2 0 0 0 −ωo ∆t 0 0 1
obtain the solution of the
0 0 0 0 1 0
0 0 0 0 0 1
The linearized state propagation is given by: xk+1 = Axk + Buk
(3)
The attitude kinematics and dynamics for a rigid body are represented here using the quaternion formulation q with scalar in the first position of the vector. It is possible to arrange equivalent formulations for other attitude representations such as Euler angles, Rodrigues Parameters or even the Rotation Matrices. The attitude model considers a rigid body with internal control moments and a potential function that depends only on the attitude. The attitude kinematics using the quaternion representation with scalar first are given by the following equation: 0 −ω1 −ω2 −ω3 1 0 ω3 −ω2 ω q˙ = 1 (4) q 2 ω2 −ω3 0 ω1 ω3 ω2 −ω1 0 Euler’s equation gives the attitude dynamics for each individual satellite: Jω˙ = Jω × ω + τ
(5)
The torque in Euler’s equation can be expanded in two main categories: 1) external torque, τ ext , (from gravity gradient, solar radiation pressure, etc.) and 2) internal torque also better known as control torque, τ ctr , (from reaction wheels, magnetic torque rods, etc.). This way τ = τ ext + τ ctr . For simplicity we will only use the gravity gradient torque as an external torque and assume that all the remaining environmental torques are negligible. The gravity gradient torque can be modeled as: τ g = 3ωo2 zo × Jzo
(6)
We can now write Euler’s equation more explicitly: ω˙ = J−1 Jω × ω + 3ωo2 zo × Jzo + τ ctr
(7)
In the Euler dynamics equation the following are constants: the inertia tensor J, Earth’s gravitational parameter µEarth , and for simplicity we can assume that the satellite orbit is circular and so the satellite orbital radius rsat is constant. The variables are the angular velocity of the satellite ω, the z-axis vector of orbital frame zo and the control torque vector τ ctr .
V.
6Dof Guidance, Navigation and Control Framework
The GNC framework was developed as a module within COSMOS as the underlaying architecture for simulating realistic coordination and motion control of multiple small spacecraft. The proposed GNC framework unifies relative navigation solutions and real-time guidance concepts. The GNC principles are employed to each spacecraft with a modular approach for better integration of these GNC functions into multiple small 9 of 13 American Institute of Aeronautics and Astronautics
satellites independently of their relative motion. Fig. 4 is a diagram with the representation of the GNC software implemented using COSMOS. Each COSMOS agent shares the information through the “spacenetwork”, that at this moment is assumed to exist just like a typical ground ethernet network where the data flows seamlessly and each node functions sends and receives data to all the other nodes instantly. In a more realistic approach the space-network must be carefully defined. 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 problems as an explicit optimizing method13 but it is now adapted for spacecraft rendezvous and docking. Part of the E-guidance scheme is the E-matrix that relates the desired final state with the current state, this creates a mechanism to compute the guidance coefficients for efficient maneuvering of spacecraft. The E-guidance formulation for this particular problem is expressed by the E-Matrix that is a scaling factor matrix: " E=
4.0/Tgo 2 −6.0/Tgo
2 −6.0/Tgo 3 12.0/Tgo
# (8)
P-vector, that is an equivalent to an error to target vector that accounts for the difference from current position state to the desired target state: " Pi =
xdi
x˙di − x˙ i − (xi + x˙ i Tgo )
# i = x, y, z
(9)
for the attitude guidance we take advantage of the quaternion vector that accounts for the angular difference (q1 , q2 , q3 ) " # q˙d i − q˙i Pi = i = x, y, z (10) xqi − (qi + q˙i Tgo ) and the C-matrix, which is the product of the E-matrix and P-vector: Ci = EPi , i = x, y, z, q1 , q2 , q3
(11)
Finally the control forces and torques are computed from the C-vector coefficients: fx = (Cx1 p1 + Cx2 p2 ) − 2ω y˙ − 3ω 2 x
(12)
fy = (Cy1 p1 + Cy2 p2 ) − 2ω x˙
(13)
2
fz = (Cz1 p1 + Cz2 p2 ) + ω x˙
(14)
τx = (Cqx 1 p1 + Cqx 2 p2 )
(15)
τy = (Cqy 1 p1 + Cqy 2 p2 )
(16)
τz = (Cqz 1 p1 + Cqz 2 p2 )
(17)
The acceleration factor in this problem is changed from the original formulation of the E-guidance described in.13 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.
VI.
Simulations
The simulation scenario consists of four cubesats that are separated from the launcher with a typical separation velocity of 1 m/s. Each cubesat is separated by 90 degrees around the spin axis of the launch vehicle. The scenario considers simplified conditions compared to a realistic launch, the objective is to test 10 of 13 American Institute of Aeronautics and Astronautics
the algorithms and proposed method. The cubesats are considered to be fully actuated with six thrusters for position control and three reaction wheels for attitude control. The preliminary simulations and visualization programs are run on a 3.11 GHz AMD FX(tm)-8120 Eight-Core processor with 16GB of RAM. The docking maneuver requires the cubesats to navigate from any given initial condition and arrive with optimal performance to a target position and designated velocity, in this case the designated velocity is zero. The docking sequence is chosen according to Fig. 7 so that the probability of collisions between each cubesat is minimized. 4
X 1
3
Y
2
Figure 7. The diagram shows the docking sequence for this particular simulation of 4 cubesats. Each arrow represents the direction of the cubesat trajectory. This sequence prevents collisions between each cubesat.
Figure 9 shows the evolution of the state position and velocity of the cubesat-1. The other cubesats have similar performance curves. The cubesat maneuvers exhibit the expected behavior since the launcher vehicle needs to expel the cubesats from the payload stack with the prescribed exit velocity and then have to come back the target position which in this case was the origin of the orbital frame. The maneuvers are optimal in terms of energy expenditure according to the E-guidance formulation. A fixed trip duration was chosen a priori for each cubesat, for cubesat-1 Tgo1 = 1000s, for cubesat-2 Tgo2 = 1100s, for cubesat-3 Tgo3 = 1200s, for cubesat-4 Tgo4 = 1500s,
VII.
Conclusion
The recent emergence of new propulsion technologies for cubesats will enable docking missions with cubesats in the near future. In this work we introduce an adapted E-guidance method as a complete 6DoF GNC framework for docking multiple cubesats. The 6DoF GNC framework computes in real time, near to optimal coupled motion in position and attitude for fully actuated spacecraft considering a proper rigid body dynamics and orbital mechanics. This GNC framework is integrated into the COSMOS system that is being developed by the Hawaii Space Flight Laboratory as a mission operations system and mission simulation/rehearsal for multi satellite missions. An essential element of the cooperative control for the cubesats is the use of the COSMOS agents that are the connecting element between each satellite GNC framework. We use COSMOS and the C++ programming language for developing the simulation framework and propose that C++11 can be modern and viable language for simulating and running complex docking scenarios; is also a proper language for code implementation in future space missions closing the gap between the design-phase/simulations to implementation. A case study is presented for rendezvous and docking of four cubesats deployed from a payload stack of a rocket. Future work will look into underactuated cubesats and more sophisticated collision avoidance mechanisms for docking multiple cubesats.
11 of 13 American Institute of Aeronautics and Astronautics
Figure 8. Docking maneuvers performance of 4 cubesats. The plot on the top shows the absolute distance of each cubesat to its target position. Each column of plots represents the attitude performance of each satellite starting on cubesat 1 on the left.
Figure 9. Position and velocity for simulated soft rendezvous and docking of cubesat-1 with target satellite using E-guidance
12 of 13 American Institute of Aeronautics and Astronautics
References 1 W. Fehse, Automated Rendezvous and Docking of Spacecraft. Cambridge: Cambridge University Press, 2003. [Online]. Available: http://ebooks.cambridge.org/ref/id/CBO9780511543388 2 NASA Press Release, “Cubesat Proximity Operations Demonstration (CPOD).” [Online]. Available: http://www.nasa.gov/ directorates/spacetech/small spacecraft/cpod project.html 3 C. Underwood and S. Pellegrino, “Autonomous Assembly of a Reconfigurable Space Tele- scope ( AAReST ) for Astronomy and Earth Observation,” in 8th IAA Symposium on Small Satellites for Earth Observation, Berlin, Germany. 4 T. C. Sorensen, C. V. Hude, M. H. Kobayashi, E. J. Pilger, A. K. Sanyal, L. K. Yoneshige, and M. 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. 5 M. A. Nunes, “Satellite Constellation Optimization Method for Future Earth Observation Missions Using Small Satellites,” Advances in the Astronautical Sciences, vol. 146, pp. 159–179, 2013. 6 T. C. Sorensen, E. J. Pilger, M. S. Wood, M. A. Nunes, and L. K. Yoneshige, “Mission design and operations of a constellation of small satellites for remote sensing,” in SPIE 8739, Sensors and Systems for Space Applications VI, 873906 (May 21, 2013), K. D. Pham, J. L. Cox, R. T. Howard, and G. Chen, Eds., May 2013, p. 873906. [Online]. Available: http://proceedings.spiedigitallibrary.org/proceeding.aspx?doi=10.1117/12.2016745 7 T. C. Sorensen, E. J. Pilger, M. S. Wood, M. A. Nunes, and B. 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. 8 T. C. Sorensen, E. J. Pilger, M. S. Wood, M. A. Nunes, H. M. Garbeil, E. K. Wessel, and W. Jamroz, “Adapting an Openarchitecture mission Operations System for a Lunar Rover Mission,” in 63rd International Astronautical Congress, Naples, Italy, 2012. 9 T. C. Sorensen, E. J. Pilger, M. S. Wood, and M. A. Nunes, “A University-developed Comprehensive Open-architecture Space Mission Operations System (COSMOS) to Operate Multiple Space Vehicles.” in SpaceOps 2012 Conference. Cleared for public release by NASA Ames, 2012. 10 M. Kobilarov and S. Pellegrino, “Trajectory Planning for CubeSat Short-Time-Scale Proximity Operations,” Journal of Guidance, Control, and Dynamics, vol. 37, no. 2, pp. 566–579, Mar. 2014. [Online]. Available: http://arc.aiaa.org/doi/abs/10.2514/1.60289 11 J. M. Phillips, L. E. Kavraki, and N. Bedrosian, “Spacecraft Rendezvous and Docking With Real-Time Randomized Optimization,” in AIAA Guidance, Navigation and Control Conference, 2003. 12 S. B. McCamish and M. Romano, “Autonomous Distributed Control of Simultaneous Multiple Spacecraft Proximity Maneuvers,” IEEE Transactions on Automation Science and Engineering, vol. 7, no. 3, pp. 630–644, Jul. 2010. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5427004 13 G. W. Cherry, “E Guidance - A General Explicit, Optimizing Guidance Law for Rocket-Propelled Spacecraft, Apollo Guidance and Navigation,” MIT Instrumentation Lab, Tech. Rep., 1964.
13 of 13 American Institute of Aeronautics and Astronautics
