Ground Station Modelling

[shughes]

This is a thread that documents our discussion that took place via email.. and continues the discussion so we can refine the model to meet our needs

[shughes]

My Initial Comments

Here is a script snippet that provides a starting point for defining ground station properties

Create GroundStation AEOS
AEOS.MeasurementModels = Angles % options include{OneWayRange,TwoWayRange, RangeRate, ...
OneWayDoppler,TwoWayDoppler, Angles, Optical, Delta-DOR}
AEOS.DataFormat = {TDRSS....DSN.. etc.}
AEOS.ReferenceBody = Earth;
AEOS.Longitude =
AEOS.Latitutde =
AEOS.Height =
AEOS.AntennaAzimuth =
AEOS.AntennaElevation =
AEOS.AntennaMaskAzimuth = % This would be a vector
AEOS.AntennaMaskElevation = % This would be a vector
AEOS.AreaMaskAzimuth = % This would be a vector
AEOS.AreaMaskElevation = % This would be a vector
AEOS.TransmitFrequency =
AEOS.ReceiveFrequency =
AEOS.FrequencyRampingFunction =
%----- Biases needed for OD
AEOS.LongitudeBias =
AEOS.LatitutdeBias =
AEOS.HeightBias =
AEOS.AntennaAzimuthBias =
AEOS.AntennaElevationBias =
AEOS.TransmitFrequencyBias =
AEOS.ReceiveFrequencyBias =
AEOS.FrequencyRampingFunctionBias =
AEOS.TimeBias
%----- Standard deviations need for OD
AEOS.LongitudeSTD =
AEOS.LatitutdeSTD =
AEOS.HeightSTD =
AEOS.AntennaAzimuthSTD =
AEOS.AntennaElevationSTD =
AEOS.TransmitFrequencySTD =
AEOS.ReceiveFrequencySTD =
AEOS.FrequencyRampingFunctionSTD =
AEOS.TimeSTD =

[shughes]

If the site is reading in real data, it would be useful to have a flag
indicating whether or not certain corrections have already been applied
to the data (e.g. diurnal aberration, tropospheric delay...).
Similarly, if it's being used to generate simulated observations, the
flag would indicate whether or not to add those corrections in.

Is the first mnemonic/label the site name? It can also be useful to
have a site numeric ID (usually numeric integer) for implementation book
keeping when several sites are processed/generated over a pass.

Site coordinates could alternatively be inpute as ECEF Cartesian. Do we
need to sepcify unites (KM, DEG) for the site parameters? Geodetic Lat
and Lon can also sometimes be specified as deg:min:sec or hrs:min:sec.
If added, space-based observers (suggested in my now obsolete additions
to the spreadsheet) would need special treatment, since they are both
"observing sites" and satellites.

Some site coordinate specifications allow for tectonic plate motion
models, where the coordinates are time-dependent relative to an
established reference frame. The coordinate rates are typically
specified based on measurement reductions (GSFC has a good database for
SLR sites on-line). This might be overkill for us (unless Haleakala
decides to become un-dormant).

Might need/want to specify the reference frame of the site coordinates.
Likewise for the optical measurements. They need a reference frame
specified.

[shughes]

To add to Tom's comments, I wouldn't want the sensor-site method to keep
tabs of media corrections. Whenever observations are being generated from
mathematical formulations (i.e. predicted observation based upon states and
times), this observation prediction function must have a way to know about,
do, or not do certain corrections or perturbations of the observable itself.


I would also like to add that sensor-site locations should also have an
associated covariance.

GMAT must also have ancillary information to formaulate a specific
observation like Earth-Orientation-Parameters, Media effects (i.e. seasonal
models), target one-way-light-time, etc.

Having both sensor-site names and ID numbers would be good.

As for the horizon mask, I don't know what you intend to do there. JPL uses
4th order Chebyshev polynomials to interpolate from up to 11 segemnts of the
horizon mask. What do I mean here? Well, assume that you have the horizon
mask in 1 degree increments from 0 to 360 (i.e. you have an azimuth
elevation pair at each increment). JPL's code will break that into up to 11
segments and use the 4th order Chebyshev polynomial to interpolate the az-el
contraint within each of those 11 segemnts. Anyway, probably more info than
you needed. Given a 2-by-n matrix of az-el pairs for the mask, it will
create the JPL code format input and the appropriate 4th order Chebyzhev
polynomial coefficients.

And...a prossible choice of formats for the sensor-site location may be:

. CARTESIAN coordinates:
1. Earth-fixed x coordindate (km),
2. Earth-fixed y coordindate (km), and
3. Earth-fixed z coordindate (km).

. GEODETIC coordinates:
1. longitude, positive East, lambda (deg),
2. geodetic latitude, phi (deg), and
3. altitude above the reference ellopsoid, h (km).

. SPHERICAL coordinates:
1. longitude, postive East, lambda (deg),
2. geocentric latitude, phi (deg), and
3. radius from the center of the Earth, R (km).

. CYLINDRICAL coordinates:
1. longitude, positive East, lambda (deg),
2. height above the equator, v (km), and
3. distance from the spin axis, u (km).

[shughes]

To me, this doesn't look like the way I'd prefer that we proceed. I'd rather be more modular in design than it appears that the scripting is supporting. We could, of course, hide the modularity from the user, but I'm not convinced that that is a useful way to proceed. Basically, what I'm saying here is that I'd prefer to break things apart more than I see in the scripting.

In terms of design, I'd want to have a class that represents the physical location of the ground station (GS), which contains an instance of an antenna. (Should that be one or more antennae? My OD experience is at least 10 years out of date -- do you ever have a GS with, for example, 2 dishes but only one specified ECEF location?) Each antenna uses a model of the data it measures -- so each antenna has one or more signal model, and that is the model accessed in the OD solver for the measured data.

With this architecture:

* Instances of the GS class contain the locational data (lat, long, height, or Cartesian data in BCBF (body-centered, body-fixed, with Earth as the default body) coordinates. Internally stored as BCBF, I suspect), the area mask data stored as a 2 by n array, and the biases associated with the positional data.
* The antenna has its mask data (in a 2 by n array, again), angle data, and angle biases.
* The signal model contains the data associated with the signal -- frequencies, the speed of light, and other elements as complexity grows.

There are lots of details to break out, of course -- interpolation for the mask data, for example -- but this is the basic tact that I'd recommend. This approach has several features that I like:

* The GS class is just a point on a central body. We can use it to specify a sensor target down the road if we want.
* The antenna model can also be used -- some extension required, I'm sure -- to specify sensors on spacecraft when we are ready for that phase of things.
* The signal models can be tailored by users for different measurements. A new measurement model implies construction of a matching signal model, and that piece is isolated from the rest of the system, so a new model can be added by understanding that piece of the interface, without needing to read and understand the entirety of the ground station subsystem. IMO, this is the critical part to get right, because, at least for a while, every time you turn around, a new measurement model will be needed.

So what does this mean for the scripting? Maybe nothing -- it could all be accomplished with the scripting you are suggesting (except the flexibility in the signal model, unless the list you specified is just meant to be representative). But I think it may be better to do something like this:

Create GroundStation AEOS
AEOS.Antenna.Mask = MaskArray % This would be a 2 x n array;
% "Antenna" is the default antenna,
% use "Add" to attach another one if
% needed

Create MeasurementModel AEOSAngles;
AEOSAngles.Type = Angles;

AEOS.Antenna.DataType = AEOSAngles;

and add other properties as needed. I'd definitely recommend making the masks 2 x n (for n points on the mask), because that simplifies debugging and testing. Passing in Az and El separately means we have to run at least 3 tests -- identically sized vectors, Az longer than El, and Az shorter than El. We know there is a 1:1 relationship between azimuth and elevation, so let's enforce it in the scripting.

[shughes]

(Background info: Steve pointed out to me on the phone that we already have an issue of putting the same object into multiple containers with the current Tank and Thruster code -- basically, we can configure a fuel tank or a thruster and attach it to several spacecraft. That makes it easy to build a formation of identical spacecraft with replicated hardware, but necessitates deep nesting when we need to access, for instance, a specific thruster on a specific spacecraft. This message presents a possible solution to that issue.)

In terms of the conflict between object replication and name uniqueness, we could add a new type of construction to the scripting language that lets us replicate a single configured object into uniquely named copies. I'm not sure that that sentence parses very well, so let me give you an example. In the current scripting, we would build a formation that has a tank and thruster like this:

Create Spacecraft sc1 sc2 sc3 sc4

Create FuelTank tank
Create Thruster Star37 % What Clementine used

Star37.Element1 = 1;
Star37.Element2 = 0;
Star37.Element3 = 0;
Star37.C1 = 500;
Star37.K1 = 2150;
Star37.CoordinateSystem = MJ2000EarthEquator;
Star37.ThrustScaleFactor = 0.995 % This is what the manufacturer claims

sc1.Tanks = {tank}
sc1.Thrusters = (Star37)
sc2.Tanks = {tank}
sc2.Thrusters = (Star37)
sc3.Tanks = {tank}
sc3.Thrusters = (Star37)
sc4.Tanks = {tank}
sc4.Thrusters = (Star37)

Each of the four spacecraft have identical Star23 thrusters, and a script writer would make individual changes to the truster properties like this:

% TSF results from fitting OD data across a burn
sc1.Star37.ThrustScaleFactor = 0.98;
sc2.Star37.ThrustScaleFactor = 0.73; % A dented nozzle -- who kicked it?
sc3.Star37.ThrustScaleFactor = 1.01;
sc4.Star37.ThrustScaleFactor = 0.97;

Instead we could do something like this without too much disturbance to the design (changes in red):

Create Spacecraft sc1 sc2 sc3 sc4

% Something like C's typedefs here
CreateType FuelTank starTank
CreateType Thruster Star37 % What Clementine used

Create starTank sc1Tank sc2Tank sc3Tank sc4Tank
Create Star37 sc1Star sc2Star sc3Star sc4Star

% Setting on the type sets it on all instances!
Star37.Element1 = 1;
Star37.Element2 = 0;
Star37.Element3 = 0;
Star37.C1 = 500;
Star37.K1 = 2150;
Star37.CoordinateSystem = MJ2000EarthEquator;
Star37.ThrustScaleFactor = 0.995 % This is what the manufacturer claims

sc1.Tanks = {sc1Tank}
sc1.Thrusters = (sc1Star)
sc2.Tanks = {sc2Tank}
sc2.Thrusters = (sc2Star)
sc3.Tanks = {sc3Tank}
sc3.Thrusters = (sc3Star)
sc4.Tanks = {sc4Tank}
sc4.Thrusters = (sc4Star)

(I only needed 2 additional lines of executable scripting here.) The properties set on the type name (Star37 here) would be set on every instance of that type of object. So the line

Star37.ThrustScaleFactor = 0.995 % This is what the manufacturer claims

sets the thrust scale factor for all of the Star37 engines to 0.995. I suspect that we'd only let this happen in object mode, and not in the Mission Control Sequence. In the Mission Control Sequence -- or a Function Control Sequence, once Wendy and Linda have worked their magic -- the script writer would have to access individual objects. This is what the earlier example would look like under this proposal:

% TSF results from fitting OD data
sc1Star.ThrustScaleFactor = 0.98;
sc2Star.ThrustScaleFactor = 0.73; % A dented nozzle -- who kicked it?
sc3Star.ThrustScaleFactor = 1.01;
sc4Star.ThrustScaleFactor = 0.97;

Here we do not need to identify the spacecraft, because the thruster name is unique. But we still have the luxury of a single property setting section for all of the Star37 objects when configuring the spacecraft.

In terms of the design and code, this would require some changes in the Moderator to know about the CreateType lines and what to do when a Create is parsed for a defined type, and some extension to the ConfigurationManager so that settings for the new types get passed to all of the instances. There are also changes in how the instances are managed. I think the only place that the current implementation is impacted (if we do this or something similar sooner rather than later) is in the spacecraft hardware -- that is, the tanks and thrusters. We need to be in that code sometime soon anyway to address finite burn.

[aero9600]

I've been working on creating the Ground Station class. Currently, I have created an Observer base class that has Ground Stations and Space Based Observers as derived classes. Currently, the SBO class is a shell and not fully fleshed out as I'm focusing on getting the ground stations functional first. When I created the Observer class, I based it off of the Space Object class. As such, the position, velocity, and "attitude" information that are required of a ground station are mostly captured already. In this sense, the "attitude" of the sensor describes where the antenna is pointing.

Also, for SBOs I left in the Thruster/Tank container information as I assumed that we would need to associate each SBO with another predefined satellite. Therefore, the "location" of the SBO will be inherited from the satellite that "owns" it. Tom is correct that we will need to define a reference coordinate system for each observer and this will be most important for the SBO class.

In my estimation, each ground station will typically only be associated with one sensor. I also plan on having multiple ways of naming/locating a ground station (Acronym, full name, station code, country, CDDIS SODs, IERS DOMES numbers, Monument Number, etc). All of these bits of information will distinguish co-located sensors from one another.

Ground station locations are specified in a number of different ways (as discussed above), but the most common are Lat,Lon, Hgt and Cartesian and we can add in other representations later. I've created a Latitude, Longitude, and Height (latLonHgt) class that is based off of the Spherical class that converts between the most typical specifications of (Lat,Lon,Hgt) and Cartesian (X,Y,Z). Since this is not a true spherical representation, my thought is that this will be a distinct class from the current Spherical class. The LatLonHgt class also allows you to compute the various forms of Latitude and height and convert between them (Geocentric, Geodetic, Reduced). I think we will have to decide what the standard location representation will be because our measurement models will need to access this location information without having to check and see what is defined and what isn't. I think it would be best to assume that all stations will have their cartesian coordinates defined and if the user specifies lat,lon,hgt the code will compute the cartesian coordinates and store them for later use. Currently I assume that all angles are specified in degrees and the height is specified in kilometers.

I want to tie in to the WGS96 undulation of the geoid to be able to compute the precise heights above the geoid. Right now everything is referenced to the ellipsoid in my LatLonHgt class. I think I found that at least one WGS standard is implemented in GMAT currently. If someone can give me an example of how to compute the undulation of the geoid currently within GMAT, I would appreciate it.

[shughes]

Hey Matt,

Here are a few comments and questions that would help me understand where you're going with your work.

1) First off, GMAT does not currently have the WGS96 model.
2) Do you have any class diagrams you could include in this thread? Perhaps you could use DoxyGen.
3) If I understand correctly, an observer can be a ground station or spacecraft. Are there other types we'll eventually need to include?
4) If I am user, and I create an Observer called AEOS, and a spacecraft called Shuttle,
- How would I congifure AEOS and what parameters can I set
- How will I ask GMAT to give me the declination of Shuttle with respect to AEOS, and similarly, other measurement models when appropriate?

Guess that's all for now, sounds like you making a lot of progress.

Steve

[aero9600]

1) Ok, well I have the WGS96 fortran source code. I'll write a C++ class to access it because I can't find anything in the current GMAT source code that would accomodate it. For more info go here.

2) I just downloaded and installed Doxygen. I'll try and get a class diagram posted.

3) The only thing we would need to possibly include are ship based and airplane based observers (all of which STK has). So, I think it might be better to shift the nomenclature of the observer class that I'm creating to have either static stations fixed to the surface of a planet or attached to a mobile object. That mobile object could be a ship, an airplane, or a spacecraft. In essence, the station would inherit the position and velocity of the parent object (be it planet or craft). I'm thinking the classes will derive as follows with base classes on the left and derived classes on the right. Each derived observer will have a measurement model that is defined with it. The measurement models I think should be friend classes so that they can be associated with any of the parent objects

Observer -> MobileObserver -> Ship -> Radar,Optical,ElectroOptical
Observer -> MobileObserver -> Airplane -> Radar,Optical,ElectroOptical
Observer -> MobileObserver -> Spacecraft -> Radar,Optical,ElectroOptical
Observer -> GroundStation -> SLR, Radar,Optical,ElectroOptical

4) I think this goes back to a question previously about keeping track of whether data is real or simulated. I think that the observer class will merely define the location and capabilities of an observer. If you want GMAT to simulate observations, then you will need to define a tasker (which is yet to be created). In the absence of a tasker, observation data supplied to an estimator via an external data file or database is just data. In the end, the user should know if that external data is real or simulated. That being said, it think that an AEOS object would be defined very similar to what was said above. In this case EOGroundStation is a derived class of GroundStation and would have measurement model parameters that can be defined that are specific to EO systems.

Create EOGoundStation AEOS;
AEOS.Latitude = 20.706486; % degrees
AEOS.Longitude = 203.743084; % degrees
AEOS.Height = 3.056277; % km
AEOS.LatType = "Geodetic"; % Geodetic, Geocentric, Reduced
AEOS.HeigtRef = "Ellipsoid"; % Geoid, Ellipsoid, MeanSeaLevel
AEOS.Name = "Advanced Electro-Optical System";

.... etc ....

Now say the Shuttle has been created as a space object.
Create Spacecraft Shuttle
Shuttle.X = 1234.5;
Shuttle.Y = blah;
Shuttle.Z = foo;
.... etc ...

If one wanted to compute various items of interest such as whether or not the Shuttle was currently in view of AEOS and if so what is the RA and Dec of the Shuttle, then I would imagine something like this:

AEOS.RADEC(Shuttle,DesiredTime);

which would output a single RADEC angle pair or

AEOS.RADEC(Shuttle,ArrayOfTimes);

which would output an array of RADEC angle pairs that could be plotted.

The RADEC capability would be a measurment model asssociated with the EO Ground Station class as would AZEL or whatever other output parameters one might desire. Now, for example, if one were to create an SLRGroundStation and try to call the RADEC measurement model, I would expect to get an error since SLR stations provide Two-way Time-of-Flight and Range.

Create SLRGroundStation Greenbelt
Greenbelt.Latitude = 39.0056; %deg
Greenbelt.Longitude =-76.6610; % deg
Greenbelt.Elevation = 0.019195; % km

Greenbelt.Range(Shuttle,ObTime); % Ok
Greenbelt.AZEL(Shuttle,Obtime); % Error!

[geno]

Can you help in modelling the Ground Station from scratch.I am not able to have access for groundstations in GMAT