[Server-sky] NORAD TLE's (3)

[Keith Lofstrom]

On Mon, Apr 06, 2009 at 10:00:25AM -0700, Tony Rick wrote:
...
> > Several issues concern me.  The accuracy of the SGP4 algorithm is
> > reportedly
...

I suggest ignoring SGP4 etc., and most of the parameters, just use
what is needed to construct ellipses and compute closest approach 
to the m288 orbit:

   Inclination
   Right Ascension of Ascending Node
   Eccentricity with assumed leading decimal
   Argument of the Perigee
   Revolutions per Day (Mean Motion)

You can compute the semimajor axis from the revolutions per day.

We cannot throw out any orbits because of true anomaly or position
along the orbits.  Potential colliders can have any orbital 
period; the chances that these are exact multiples of the m288
period is small.  So a hazard exists if server sky crosses the
ellipse, not just the particular spot where an object happens
to be.  With enough time, the object can be anywhere on the 
ellipse as server sky objects cross it.

If you start with the 3 line catalog data, you can also get the
name of the object, which contains "DEB" for debris or "R/B"
for rocket body.  That does give some indication of the value
of the object.  It would be handy to keep the time derivatives
in mind, to see if the orbit is decaying significantly (lowering
apogee), but that is not needed right away.  

Given the semimajor axis and the eccentricity, you can compute
apogee and perigee.  For now, ignore everything that cannot even
in principle cross m288 - that is, orbits with apogees below
m288 -500km or perigees above m288 +500km.  That will throw out
a lot of orbits.  

Of the orbits that are left, the first interesting thing to do
is look for "crossers", the orbits with ascending or descending
nodes in the 1000km ring.  I expect that to capture about half
the objects we are interested in.  

Then there are the "grazers", which are a bit more difficult to
define.  These will pass through the torus above or below the
equatorial plane.   They will be harder to find.

The easiest way to do this is to remap the orbits onto a two
dimensional half plane,  with a "v" (north/south) axis and an
"r" radial axis.  I don't know what the locus will look like,
but some will resemble distorted ellipses.  Then look for those
orbits that cross the boundaries of, or lay within the m288 torus.
The boundary will look like a circle on the v/r plot, approximately.

If all orbits are plotted on this half plane, the resulting 12820 or
so paths will "darken the sky" near the earth, while leaving fewer
traces at higher values of z.  What we are interested in is the 
density near m288.

There will be 6 classes of objects:
   1) Apogee too low
   2) Perigee too high
   3) Completely outside the m288 circle
   4) Objects crossing the m288 circle twice (ascending OR descending)
   5) Objects crossing the m288 circle four times (ascending AND descending)
   6) Completely inside the m288 circle

(4), (5), and (6) are collision hazards.  Some (3) objects may evolve
into (4) objects because of drag or collisions.  I expect there to be
few or no (6) objects.

Finding this out will probably involve looking the candidate orbits
and finding the angles from perigee where they cross the inner and
outer radii.  For most objects, the segments of the orbit that are
within the circle can be approximated as straight lines between points.

The true anomaly angle of the circle crossing positions for the
crossing orbits will be useful for plotting the colliders.  

----

The following gets a little complicated, but it describes what I
want to end up with.

On the r/v graph, all server sky objects have paths that look like
circles.  Objects make one rotation around that circle for each orbit,
and to a good approximation the angle-from-center is directly related
to the longitude. 

Lets make another "server-sky-centric" graph.  This time, we set
the center of the graph at the r0 centerpoint of the core m288 orbit.
This graph has "x" and "y" coordinates in relation to that centerpoint,
with "r-r0" and the "v" coordinates from the old graph rotated around
the centerpoint by the longitude.  In this coordinate space, server
sky objects will appear as single points.  

Performing the same transformation on the "crosser" loci, we will get
some circles ( #6 objects ) and either one or curves ( #4 objects and
#5 objects) representing the path of the object through the server sky
object plane.  These are the collision paths on the server sky plane,
and there should be no server-sky objects in them.  

A graph showing all these curves would be very interesting.   If the
graph background is black, and these curves are plotted with various
colors to indicate the type of object (active satellite, dead satellite,
rocket body, debris) then I expect to see about 300 collider lines
crossing the 1000 kilometer diameter disk.  The black areas remaining
would be the safe places to assign server-sky orbits.  

In more detail, the width of those curves represent the physical width
of intact orbiting objects.  Since the satellites and rocket bodies have
finite dimensions, typically on the order of meters, their paths would
be very thin - their tracks would not color much of the disk, and most
of the disk would be available for server sky orbits (with potentially
millions of server sky objects positioned at many true anomalies around
that orbit).

However, objects spin and shed small debris.  The shed debris does not
go flying off forever - it stays in a related orbit, probably within
a few hundred meters of the object (assuming it is not spinning wildly).
The shed debris will also be spinning, and the variation of light
pressure as it tumbles will cause it to slowly expand the "radius" of
a collider orbit.  That broadens the width of the collider object track.
In the beginning, there will also be uncertainties due to the limited
precision of the NORAD TLEs.  That will broaden those tracks, too.

Still, I expect the disk to be mostly empty for modest track widths
(say, 1 kilometer).   Even if only 10% of the disk is clear, that is
enough to orbit trillions of collision-free server-sats, and in radar
mode they can accurately resolve the orbits of potential colliders,
which will narrow the track width and free more potential orbits, as
well as create opportunities to deorbit or passivate (wrap to reduce
shedding) the worst offenders.  In time, I expect most of the disk
will be clear, and there will be strong incentives to clear the rest,
like pulling the stones out of a farmer's field and making walls from
them.  Also, with accurate ephemerides, some server-sats can occupy
dangerous positions, and jink and dodge out of the way of collider
crossings.

The above discussion is based on the approximation that server-sats
have uniform angular velocity.  Orbits with higher minor radii will
be elliptical, and change angular velocities as they orbit;  this
will affect the longitude subtraction somewhat.  There will also be
tidal effects from the sun and moon, and from the oblateness of the
earth, light pressure, and other perturbers of the server-sky and
collider object orbits.  Objects in decaying orbits will change 
their tracks with time.  Sun synchronous colliders will pose a 
special challenge, and may require that all server-sats do some
maneuvering over the course of a year.  But the disk density plot
will give some idea of the scale of the problem.  I want to design
the first objects into empty spaces until they have time to map
everything.  

Lastly, I picked m288 as a stake in the ground.  I like circular
equatorial orbits because they stay in a fixed ground antenna
elevation, well below geosynchronous antenna elevations.  However,
the above transformations work with any radius, and we might find
emptier disks centered around nearby orbits.  Once we get good at
identifying colliders, we can run through all the disk plots.

----

An note for Tony - I wrote a little Perl program to process TLE's and
identify "crossers" (though not grazers) from the 3 line catalog.  I
can send you the code, it might make a better starting point than SGP4.
It might also be good to meet for lunch sometime this week and perhaps
do a coding session.  I want to have some collision stuff ready for
PLUG Advanced Topics on the 15th.

I plot charts with gnuplot, but I am still learning how to do 3D
and animated stuff with it.  Plotting the locuses of 13K objects
on the r/v plot, or even 300 objects on the disk plot, will get
"interesting".  We probably want to use something else to do 
the plots.

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs