earthobservationsimulator / orbitpy Goto Github PK

Following warning is displayed when running the tests/validation/test_coveragecalculator_GridCoverage_with_STK.py script.

RuntimeWarning: invalid value encountered in true_divide

 percentDiff = (val1 - val2) / ((val1 + val2)/2)

Corresponding function: CoverageChecker::GetEarthFixedSatState(Real jd, const Rvector6& scCartState)

This becomes important when we wish the attitude (one of the axis) of the spacecraft to align to the spacecraft ground-track, which in turn requires one of the axis of the spacecraft body to be aligned to the spacecraft velocity in Earth-Fixed frame.

When the commented tests in the referenced file are included in testing, the error is produced. It appears that the arguments are not passed properly from the INSTANTIATE_TEST_CASE_P to the GetParam(). (Note that the last element of the clock array is not what is expected.)

This same error does not happen in the GMATCustomSensor GTest (TestGMATCustomSensor.cpp).

Maybe relevant: http://extremelearning.com.au/how-to-evenly-distribute-points-on-a-sphere-more-effectively-than-the-canonical-fibonacci-lattice

This produces a error of < 1s. Suggest to modify the time-representation to be in Gregorian Date UT1.

Negligible changes in code is required, since actually until now the indicated Gregorian Date UTC was actually Gregorian Date UT1 (conversion from Julian Date UT1 to Gregorian Date UT1 was performed without accounting for DUT1). Only the print to csv file is changed to indicate that the time is in Gregorian Date UT1.

The current process in the coveragecalculator class for writing coverage reports is inefficient.

            # compute coverage
            points = cov_checker.CheckPointCoverage() # list of indices of the GPs accessed shall be returned
            if len(points)>0: #If no ground-points are accessed at this time, skip writing the row altogether.
                for pnt in points:
                    coords = self.grid.get_lat_lon_from_index(pnt)
                    access_writer.writerow([time_index, pnt, coords.latitude, coords.longitude])

For every individual point accessed, the coordinates are requested one at a time. This requires a lot of python function calls and back and forth between python and C++. It would be better to request them all at once using something along the lines of self.grid.get_lats_lons_from_indices(pnts).

pointArray stores the normalized position vectors of the points in the PointGroup class. Move it and its calculation to the PointGroup class.

In the Propagator::Propagate(const AbsoluteDate &toDate) function the orbit-rates needs to be updated.

Currently using the propagator without drag effect consideration is acceptable, and results match well with the STK J2 Analytical Propagator.

Mail - Ravindra, Vinay (ARC-SG)[Bay Area Environmental Research Institute] - Outlook.pdf
[EXTERNAL] RE: build/start TAT-C
Ravindra, Vinay (ARC-SG)[Bay Area Environmental Research Institute]
Tue 9/15/2020 4:45 PM
Hi Paul,

Thanks for the feedback. I think the behaviour of the results with closely repeating ground track for a polar-orbit is consistent with the error in the date input to the ECI to lat/lon conversion. Perhaps the jDate was erroneously at a fixed value in the iteration loop implying in effect the rotation of Earth is not being modeled. (The latitude thus changes while longitude is nearly the same, but not the same because it is not 90 deg inclination orbit.)

I think your fix is correct. The bug is in the GMAT part of the code. Line 455, prop->Propagate (*orbitDate); which is supposed to propagate (and also update the corresponding state elements) the satellite tied with the prop object (Line 363). It appears though that only the six Cartesian states X,Y,Z,VX,VY,VZ of the satellite are being updated in the Spacecraft class (and hence the sat object) and the time is not updated.

See:
https://gitlab.tatc-git.net/tat-c/tat-c/-/blob/new_folder_structure/modules/orbits/oc/src/Propagator.cpp (Line 256)
https://gitlab.tatc-git.net/tat-c/tat-c/-/blob/new_folder_structure/modules/orbits/oc/src/Spacecraft.cpp (Line 527, the function variable 't' should perhaps be used to update Spacecraft class variable orbitEpoch)
We did not come across the same problem in Dshield since we do not use the ECI to lat/lon conversion functionality. I am surprised about that error since I remember Gabe showing some nice heat-map plots of coverage, revisits etc which spanned the entire globe. Perhaps it crept in at a later stage of the project.

Best,
Vinay

The update is about handling of a edge case concerning ray through vertex. See https://github.com/ryanketzner/sphericalpolygon/ for the updated source code.

• The destructor function in Propagator, Spacecraft have been modified to comment out the delete operation on objects (orbit-state, orbit-epoch, attitude, interpolator) to which the class instance variables point to. This is because the objects are created outside and not by the Propagator/Spacecraft classes, and hence it seems better to not have the classes delete them. Hope it doesn't create any problems.

  • (On the other hands the objects pointed to by the instance variables, can be changed by the respective classes, hence these objects have a 1-1 association with these classes, and hence would make sense for them to be deleted by the classes)

• Issue with Spacecraft class: When the copy operation is used, the objects are created by the Spacecraft class itself, in which case the deletion becomes the responsibility of the Spacecraft class.

• See the CoverageChecker class which on other hand does not create PointGroup, Spacecraft objects (in the copy function). In this case the CoverageChecker class does not change the PointGroup or Spacecraft objects. In case of Spacecraft class however the OrbitState, OrbitEpoch, Attitude, Interpolator objects can be changed by the Spacecraft class itself, which would necessitate cloning of the respective objects in the copy function.

• Memory problems may (not sure) happen if the CoverageChecker object is copied, and the copy/ original is destroyed. (Since some objects (pointArray, centralBody) appear to be shared between the copies.)

Refer the CheckGridFeasibility function in the propcov-cpp CoverageChecker class. It has a faster version for horizon check.

transformSpherical, cartesianToSpherical, sphericalToCartesian in Polygon class can be replaced with ones already available in the GMAT util library. (Note that the inc, az variables correspond to the cone, clock angles respectively)

AnglePair typdef can be revised.

Currently the grid-indexing is not customizable. It considers a list of grid-points to be indexed starting from 0, and being incremented by 1. Modify this behavior to allow for customizable indexing.

In the PointGroup class, need to modify the strict requirement on the range of longitude values. Currently the range is -pi to +pi.
While reading the grid file data, the PointGroup class filters out points not satisfying the above constraint.

See 35f5cf2

As long as this issue is there, the range of longitude values must fall within -pi to pi, else there shall be erroneous behavior, results.

Modify this behavior to also accept longitude values in the range 0 to 2pi.

Polygon::util::cartesianToSpherical function is used by the classes in the polygon folder and it forces the clock angle to be in the range 0 deg to 360 deg. Errors ensue if this forcing is removed.

It would be better to find where in the code there is actual requirement of the clock angles to be in the range 0 deg to 360 deg and perhaps add the forcing there.

Allow for coveragecalculator module to perform coverage calculations for spacecraft with no sensors. The considered FOV is the entire horizon as seen by the spacecraft.

The attitude configuration and calculations in GMAT-OC have confusing variable names and function names. For eg:

1. In Spacecraft::CheckTargetVisibility(....):

   • R_NI = GetBodyFixedToInertial(bodyFixedState); NI indicates Inertial to Nadir, but the function name is BodyFixed to Inertial. There is no Nadir in the function name?

It seems that R_NI here may actually be the rotation matrix from Earth-Fixed to Nadir. Correspondingly GetBodyFixedToInertial() must be named as GetBodyFixedToReference? where BodyFixed refers to EarthFixed and Reference refers to Nadir.

2. The function Spacecraft::GetBodyFixedToInertial(.....) is as follows:

Rmatrix33 Spacecraft::GetBodyFixedToInertial(const Rvector6 &bfState)
{
   return attitude->InertialToReference(bfState); 
}

The return matrix name and the function name does not gel.

3. In NadirPointingAttitude::InertialToReference the returned matrix is named as R_fixed_to_nadir_transposed implying it is R_nadir_to_fixed. But this does not gel with the function name InertialToReference