Leonard Vance,

Jekan Thangavelautham,

Jose Maria Fernandez Moreno

This application claims the benefit of U.S. Provisional Application Serial No.

63/159,945, filed 03-11-2021, which is hereby incorporated by reference in its entirety.

STATEMENT OF GOVERNMENT INTEREST

This invention was made with government support under contract 80NSSC19M0197, awarded by The National Aeronautics and Space Administration (NASA). The government may have certain rights in the invention.

TECHNICAL FIELD

The present disclosure relates to a satellite system with orbital debris avoidance.

BACKGROUND

The recent proliferation of low earth satellites in support of global wideband internet communications as well as a growing variety of miniature spacecraft missions has underscored the need for a systems approach to orbital debris mitigation. The Chinese AS AT test of 2007 and the subsequent Iridium/Cosmos collision of 2009 each served as reminders thatcollisions in low earth orbit are not just of academic concern, but are now a real operational concern. ESA Estimates for the number of objects in low earth orbit greater than 10 cm in size is 34,000, with estimates for smaller hut still hazardous 1-10 cm objects at 900,000. The growth of the number of objects in orbit has not been matched by an equivalent improvement in tracking capability. The advent of powerful ground-based radars with the specific intent to track orbital debris (The U.S. Space Fence) vastly improves the ability tosee objects, but the problem of track file correlations must also be solved before benefits can be fully realized.

The position uncertainty of an orbiting object can exceed 10 kilometers depending on the quality and timing of its most recent tracking sensor. Spread out over such a large volume, the actual probability of impact, even assuming perfect overlap of their respective position uncertainties isso small, and the frequency of occurrence so high, thatavoidance maneuvering is often considered not worth the price of the delta-V expended. Nevertheless, the proliferation of launch systems and the advent of various global internet satellite networks has significantly increased the number of objects in orbit, along with the real possibility of collision. Even without considering the resulting loss of costly assets, the resulting cascade of additional debris introduced by such collisions significantly worsens the problem for future operators, leading eventually (over decades to centuries) to the end state of the Kessler syndrome, where the population of lethal debris is so high that low Earth orbit missions as we understand them would not be possible.

Multiple mitigation techniques have therefore been implemented, with the aim of executing activities in support of a systems-based solution to this problem. New satellite launches must now submit debris mitigation plans which demonstrate deorbit within 20 years, and tethering has reduced the population of lens caps and other like deployables from newly commissioned spacecraft. Exploratory missions for debris capture are being planned and improved ground-based radars are being developed to reduce position and velocity uncertainties.

As one part of this solution, spacecraft-based sensors with accompanying thrusters have also been considered. In the absence of any cueing from the ground, these systems scan the spacecraft forward velocity quadrants, and track incoming debris to determine the probability of imminent collision. Theimmediate problem with such a concept is that a large volume of forward angular space must be continuously scanned for the lifetime of the satellite, which is both a significant mechanical and reliability challenge. BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of various embodiments of the claimed subject matter will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals designate like parts, and in which:

FIG. 1 illustrates a satellite system in accordance with several embodiments of the present disclosure;

FIG. 2 is a flowchart of operations according to one embodiment of the present disclosure;

FIG. 3 illustrates an example simulation according to one embodiment of the present disclosure; FIG. 4 illustrates another example simulation according to one embodiment of the present disclosure; and

FIG. 5 illustrates another example simulation according to one embodiment of the present disclosure.

Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.

DETAILED DESCRIPTION

FIG. 1 illustrates a satellite system 100 according to several embodiments of the present disclosure. As a general overview, the satellite system 100 is configured to detect orbital debris to enable a satellite to make maneuvering decisions to avoid collisions with debris. The satellite system 100 includes a satellite 102 generally configured to achieve an orbit in an orbital plane, and having a forward velocity of Vsat 124. Although not shown in the drawings, the satellite 102 may include conventional systems that may be associated with a satellite, e.g., propulsion systems, navigation systems, power systems, satellite-to-satellite communications circuitry, satellite-to-ground communications circuitry, etc., and may also include various payload systems to enable the satellite 102 to perform specific tasks, as is well-understood in the art. In embodiments described herein, the satellite 102 includes debris sensor circuitry 104 generally configured to determine the existence or absence of a debris item within a search window 112, and sensor controller circuitry 106 generally configured to control the debris sensor circuitry 104 and to enable activation and positioning of the debris sensor circuitry 104 to detect debris within a defined search window 114, as will be described in greater detail below.

In some embodiments, the debris sensor circuitry 104 may include, for example, a laser device, RADAR device, passive optical elements, etc. and/or combinations thereof. For example, debris sensor circuitry 104 may comprise continuous wave laser circuitry to enable scanning of the search window 114. In one example, a continuous wave laser sensor may be used having a range of at least 20 kilometers (range from the satellite 102 to debris within the search window 114), a power consumption of approximately 55 milliamp hours, and a beamwidth of 50prad. Of course, this is only a non-limiting example of the types of sensors that may be used according to the teachings herein. In some embodiments, the debris sensor circuitry 104 may be generally configured to scan an area (search window 114) generally in front of the satellite, and thus, may also be controllable to move and/or point to various positions within the search window 114.

Sensor controller circuitry 106 is generally configured to control the debris sensor circuitry 104 to determine if a debris item 113 is within the search window 112. Sensor controller circuitry 106 includes search window determination circuitry 108 generally configured to determine a size of the search window 114 (e.g., search field angle 116), as described below.

The search window 114 is generally defined within a debris position uncertainty zone 112 (“uncertainty zone 112”). The uncertainty zone 112 generally represents an area within which the position of debris items contained therein have a degree of uncertainty, such that, given these uncertainties, there exists a non-zero probability of collision of a debris item in this zone 112. To determine the size (angular extent) of the uncertainty zone 112, the present disclosure may utilize ground-based collision alert systems. For example, the system 100 may include ground-based collision prediction circuitry 130 generally configured to determine if one or more debris items may collide with the satellite 102. As is known, velocity and position data of space debris may be tracked by various governmental entities (e.g., NORAD, Space Command, etc.) and/or private entities, and such velocity and position data may be stored in a common format, for example a two-line element (TLE) database format, etc. While velocity data associated with each debris item is generally considered highly accurate (e.g., accurate to within 1-10 cm/s, etc.), positional data associated with each debris item tends to be far less accurate, due to, for example, orbital dynamics (e.g., gravitational effects, etc.) that can cause positional changes. Such TLE data (and/or other debris velocity/position data) may be updated continuously (e.g., daily, weekly, etc.) so that the database generally is complete and accurate (with respect to debris velocity data).

Collision prediction circuitry 130 is configured to determine collision alert data based on known space debris data 132 (e.g., TLE data) and satellite data 134. The space debris data 132 may include velocity and/or position data concerning known debris items (Vdebris 122). The satellite data 134 may include velocity data (Vsat 124) of the satellite 102 (and may also include orbital parameters, etc.). To determine a potential collision between a debris item and the satellite 102, the collision prediction circuitry 130 may be configured to model debris behavior and determine potential satellite-crossing paths. In one example embodiment, the collision prediction circuitry 130 may be configured to execute a Simplified General Perturbations 4 (SGP4) model to generate future debris position and velocity based on, for example, earth oblatenessm aerodynamic drag, perturbations of the moon and sun, etc., to determine orbital trajectories and characteristic uncertainties of debris items over a selected time horizon (e.g., days, weeks, months, and/or at times when the satellite 102 will be known to be crossing a known debris field, etc.). This model can propagate errors in state estimates for debris objects to establish debris velocity uncertainties. Of course, this model is provided as an example, and in other embodiments other conventional and/or proprietary debris modelling tools may be used. Because of positional uncertainties of debris items, the collision prediction circuitry 130 defines the uncertainty zone 114, which includes any debris item(s) that may potentially cross paths with the satellite 102. Thus, the uncertainty zone 112 may contain one or more debris items that have a high probability of collision (e.g., 95 % confidence, and/or other confidence level), and these items are represented in the collision alert data. The collision alert data may also include the position and extent of the uncertainty zone 112, and an approximate time of collision. The collision alert data may be transmitted to the satellite 102 (via communications network 118), and stored in storage device 110.

The search window determination circuitry 108 is configured to determine the size of search window 114 (or, stated another way, determine the search field angle q 116) based on uncertainties of Vdebris 122 and Vsat 124 (shown generally as velocity uncertainties Vu 140), uncertainties of pointing errors associated with sensor circuitry 104 (shown generally as sensor uncertainties Su 142), the size of the satellite 102, and also based on the collision alert data 110 (which, as described above, provides the size of the uncertainty zone 112 and the approximate time of a predicted collision event). In one example embodiment the search window determination circuitry 108 may determine the search field angle q 116 using root-sum-square (RSS) and/or root-mean- square (RMS) functions of the uncertainty in velocity and sensor accuracy. For example, the search window determination circuitry 108 may be configured to execute a root-mean-square function that provides an approximation of angular search uncertainty, for example:

B = sqrt ((Vu/Vm) ^A 2 + (Lsat/6Rm) ^A 2 + (Au) ^A 2); where sqrt is a square root function, Vu is the uncertainty of the relative closing velocity (shown as Vrel 126), Vm is the magnitude of the closing velocity, Last is the length (or width) of the satellite (i.e., the dimension exposed to oncoming debris), Rrn is the range magnitude to the debris field along the closing velocity vector Vrel 126 (represented as line 119 in FIG. 1 from the debris sensor circuitry 104 to the approximate middle of the search window 114), and Au is the alignment uncertainty of the sensor system relative to a selected coordinate frame (e.g., xy coordinates, polar coordinates, etc.)

With B (the angular search uncertainty), the search window determination circuitry 108 may determine the search field angle q 116 as:

Q = 6B.

As a general matter, the size of the search window 114 is generally much smaller (e.g., orders of magnitude smaller) than the uncertainty zone 112 generated by the collision prediction circuitry 130, and thus provides a significant advancement over current debris avoidance systems. The sensor controller circuitry 106 may enable the sensor circuitry 104 to scan the search window 114, at the time of a predicted collision event, to determine an existence or absence of a debris item. In some embodiments, sensor controller circuitry 106 may generate sensor movement control signals to control the debris sensor circuitry 104 to in a predetermined pattern within the search window 112. For example, the predetermined pattern may include a left-to-right, top-to-bottom scanning pattern. Depending on, for example, the beamwidth and/or sensitivity of the debris sensor circuitry 104, the sensor controller circuitry 106 may accomplish one or more scans of each debris items in the search window 112.

If, during a scan of the search window 114 a debris item is detected (for example debris item 113) there exists a probability of collision that exceeds probability of collision threshold. Accordingly, the sensor controller circuitry 108 may also be configured to generate avoidance control signal(s) 105. The avoidance control signal(s) 105 may include, for example, propulsion and/or steering instructions to enable the satellite 102 to speed up, slow down and/or change trajectory to avoid collision with the debris item 113. Such instructions may be used by, for example, propulsion and/or guidance systems (not show) associated with the satellite 102.

It should be noted that although the collision prediction circuitry 130 is described above as a ground-based processing platform, the collision prediction circuitry 130 may, in other embodiments, be incorporated within satellite 102, depending on processing requirements, power requirements, etc. FIG. 2 illustrates a flowchart 200 of operations for space debris avoidance according to one embodiment of the present disclosure. Operations of this embodiment include identifying a debris field in a crossing path to a satellite 202. The debris field may be identified using a knowledge base derived from ground-based systems that identify and track debris fields in space. Operations of this embodiment may also include determining collision alert data based on known space debris data within the debris field and velocity data of the satellite 204. Operations may also include determining an uncertainty zone of potential collisions between the satellite and one or more debris items 206. The collision alert data is generally only as accurate as the velocity and/or positional data of the debris and satellite, and thus, the collision alert data may define potential collisions within a collision uncertainty zone. Operations may also include determining a search window within the uncertainty zone, based on, at least in part, uncertainties associated with debris velocity and satellite velocity 208. A size, shape and/or position of the search window within the uncertainty may also be based on uncertainties associated with debris detection circuitry and/or uncertainties associated with a relative velocity between the satellite and at least one debris item. Operations of this embodiment also include generating avoidance instructions to enable the satellite to avoid collision with a debris item that is detected within the search window 210.

While the flowchart of FIG. 2 illustrates operations according to one embodiment, it is to be understood that not all of the operations depicted in FIG. 2 are necessary for other embodiments. In addition, it is fully contemplated herein that in other embodiments of the present disclosure, the operations depicted in FIG. 2, and/or other operations described herein may be combined in a manner not specifically shown in any of the drawings, and such embodiments may include less or more operations than are illustrated in FIG. 2. Thus, claims directed to features and/or operations that are not exactly shown in one drawing are deemed within the scope and content of the present disclosure.

FIG. 3 illustrates an example simulation 300 according to one embodiment of the present disclosure. One primary challenge for any satellite based sensor system is the sheer angular volume from which potential debris objects can approach a spacecraft. While the nature of orbital motion largely confines intercepts to the front quadrants along the velocity vector, the range of possibilities is large. Accordingly, characterization of the field of regard necessary to acquire potential collisions is established by constructing a simulation experiment using the position and velocity orbital objects derived from an epoch of the NORAD database, and then adding in a number of ’witness plates’, asvirtual objects in 880km circular orbits at 98 degrees inclination. This is illustrated on the left half of FIG. 3, generally shown at 302, depicting numerous orbital objects and numerous “witness plates” dispersed at various locations within the cloud of orbital objects around the Earth. The witness plates are considered stand-in’s for a candidate satellite. The witness plates are given a large virtual size, and thereby collect significant numbers of impacts over time in order to establish basic statistics for debris closing velocity and impact angles. The right side of FIG. 3 (304) illustrates the resulting statistics for approach angle and velocity in the right frame. The vast majority of impacts result from azimuth angles less than 70 degrees azimuth angle centered on the satellite’s velocity vector, withalmost all elevations less than a degree off local horizontal. Velocities averages can be low, but the median velocity is close to 15 km/s as the flux for near head-on collisions is higher because the satellites encounter each other more often. There is therefore a strong correlation between low azimuth angles and high closing velocity.

A sensor field of regard requirement is therefore established as ±68.3 degrees azimuth with ±1.08 degrees elevation. For the purposes of top level requirements derivation, the closing velocity is assumed at 15 km/s as values close to this dominate the distribution. The resulting angular limits do not cover all possible collisions, but represent a compromise covering 95% of the observed cases.

FIG. 4 illustrates another example simulation 400 according to one embodiment of the present disclosure. The presumption of this simulation is that the propagation of errors resulting from initial position and velocity covariances result in significant position uncertainties along the direction of travel, but only small increases in the velocity uncertainty itself. As a result, a forward-looking sensor can search along the projected velocity approach vector, ignoring the rest of the uncertainty volume because debris objects, if they are there, will not hit the spacecraft. The underlying assumptionis that the velocity uncertainties are much smaller than the position uncertainties leading to this very small required search window.

The resulting propagation of errors over time resulting from an initial state estimate drives the position and velocity uncertainties of a debris object. Since initial state covariances are not readily available for orbital objects, nor included in the standard TLE (Two Line Element) model, state vector covariances are established by propagating a TLE defined orbit for a given satellite forward by several days, and comparing the resulting states to those from a more recent TLE. The propagated position errors of a TLE provides an understanding of how fast these errors grow, and this can be used to infer corresponding initial velocity uncertainties. The SGP4 (Simplified General Perturbations 4) model takes into account a first cut at earth oblateness, aerodynamic drag, and perturbations of the moon and sun in order to establish future state predictions. Such a model may be used to propagate orbital trajectories and characterize uncertainties over time. This model is used to propagate errors in the state estimates for our debris object for the purpose of establishing velocity uncertainties. Propagated position and velocity uncertainties are then used to establish the uncertainty in the conjunction approach vector (Vrel), which in turn establishes the angular search (search widow _' angular extent) requirement for our proposed sensor.

This is accomplished by executing a simulation experiment by adding random errors to the initial velocity values derivedfrom a TLE, and propagating forwards in time seven days, and then comparing the resulting position errors to those observed. Velocity uncertainties are then adjusted up or down to match the observed position errors as a function of time, thus inferring the initial velocity estimate error. Variations on this experiment were done by providing a rough estimate of propagated errors for high inclination circular orbits at about 800 km altitude. Assuming a ±10 km in-track error over 7 days consistent with Propagating with SGP 4, infers an RMS velocity error of 1.8 mm/s in each axis. Assuming that original velocity vector error, a monte-carlo simulation is executed against a nominal intercept point to establish how often collisions actually occur. The angular positions of those that collide relative to the nominal approach vector are then established as a function of range so that search requirements can be established consistent with the acquisition range of the chosen sensor. The left frame of FIG. 4 (402) shows that the angular distribution of colliding objects is actually very small compared to the overall cloud size, with a 20 km acquisition range requiring a search window only 0.5x0.1 mrad in extent to acquire all possible colliding objects (as shown at 404). The colliding satellite is simulated 50,000 times for thisanalysis, drawing a velocity uncertainty of 0.0018 m/s RMS in all three axis before being propagated 7 days with the SPG4 orbital propagator. The resulting in-track position error was ±10km 3s at the time of the conjunction, consistent with propagation error estimates completed in references. Assuming any miss distance less than 5m constitutes a hit, this results in 810 impacts out of 50,000 cases for an impact probability of 1.62% assuming the satellite is lined up perfectly to fly through the center of the debris cloud.

FIG. 5 illustrates another example simulation 500 according to one embodiment of the present disclosure. In its simplest form, a forward- looking sensor comprises a continuous wave laser which may be scanned repeatedly over the appropriate search window established in FIG. 4. The sensor remains in standby mode for the vast majority of its time in orbit, only activating upon approach of a possible collision. Power utilization during this phase is about 100W, assuming a lasing efficiency of 20%, and can be supplemented with a battery if necessary. Battery capacity is 100W for 2 seconds, or 55 milliamp hours, which is a half gram battery given a 100 Whr/kg Lithium Ion battery energy density estimate.

Any positive detection during the 1-2 second conjunction encounter when the laser is pointing along the approach velocity vector indicates an imminent collision since w ^? eare only searching within the angular ^’ volume of position uncertainties which will result in an impact. A system trade can occur here, since longer ranges have smaller angular search volumes as well as having longer times to execute an avoidance maneuver. Nominally, 20km is chosen as the acquisition range, and this permits a beam width of 50/rrad which will execute a 10x2 scan over the prescribed angular volume derived in FIG. 4 and as shown in FIG. 5. The selected laser parameters for this simulation are tabulated at 502.

Executing the search path shown in the right frame (504) of FIG. 5 requires an average angular velocity of 1.2 mradians motion at 10 Hz, which calculates to a modest 12 mrad/s.

Propulsi ve A voidance

Assuming that we choose 20 km range as a baseline design, and a closing velocity of 15 km/s derived from FIG. 3, we therefore have 1.33 seconds of elapsed time from start of the first scan until impact. With the laser system parameters shown in the left frame of FIG. 5, it can be seen that a complete 10x2 scan can be completed in 100 msec so that the remaining elapsed time for an evasive maneuver is 1.23 seconds. Assuming that a distance of 5m is required to ensure separation, first order kinematic analysis can he completed to establish propulsive requirements for an evasivemaneuver. This shows that the satellite must accelerate at just about 6.6m/s ^z in order to avoid collision worst case.

As used in this application and in the claims, a list of items joined by the term “and/or” can mean any combination of the listed items. For example, the phrase “A, B and/or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C. As used in this application and in the claims, a list of items joined by the term “at least one of’ can mean any combination of the listed terms. For example, the phrases “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

As used in any embodiment herein, the terms “system” may refer to, for example, software, firmware and/or circuitry configured to perform any of the aforementioned operations. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory, computer-readable storage devices. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. “Circuitry”, as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry and/or future computing circuitry including, for example, massive parallelism, analog or quantum computing, hardware embodiments of accelerators such as neural net processors and non-silicon implementations of the above. The circuitry may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), application-specific integrated circuit (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, etc.

Any of the operations described herein may be implemented in a system that includes one or more non-transitory storage devices having stored therein, individually or in combination, instructions that when executed by circuitry perform the operations. Here, the circuitry may include any of the aforementioned circuitry including, for examples, one or more processors, ASICs, ICs, etc., and/or other programmable circuitry. Also, it is intended that operations described herein may be distributed across a plurality of physical devices, such as processing structures at more than one different physical location. The storage device includes any type of tangible medium, for example, any type of disk including hard disks, floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, Solid State Disks (SSDs), embedded multimedia cards (eMMCs), secure digital input/output (SDIO) cards, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Other embodiments may be implemented as software executed by a programmable control device.

The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents. Various features, aspects, and embodiments have been described herein. The features, aspects, and embodiments are susceptible to combination with one another as well as to variation and modification, as will be understood by those having skill in the art. The present disclosure should, therefore, be considered to encompass such combinations, variations, and modifications.

Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.