We are a group of rising senior Aerospace engineers in a capstone project. Our team is tasked with analyzing modern flight dynamics SW such that they could be implemented with the company we are in collaboration. At this point we have chosen Orekit since it goes above and beyond the minimum viable product that was given to us in the form of an RFP.
We are trying to develop a demonstration showcasing Orekit’s capabilities, specifically with the numerical propagation function.
We were hoping to get some start-up tips, especially pertaining to inputting some standard data sets used for NASA missions, for example, as a baseline for propagation and estimation. How could this data be inputted in place for the dummy data given in the Orekit tutorials?
Any and all advice moving forward would be highly appreciated and beneficial.
Welcome to the Orekit forum! And thank you for selecting for your demonstration.
You can find tutorials on the Orekit tutorials project. These are Java tutorials showing the main features of Orekit. And there is one tutorial for the orbit propagation named NumericalPropagation.java. This tutorial presents how to initialize an orbit and a numerical propagator.
You may also have a look at the covariance propagation tutorial. One of the features it demonstrates is how to load data from a standard CCSDS file. In this case it is an OPM file, but many other CCSDS formats are supported in a similar way. The description of CCSDS loading/writing features can be found here.
The data contexts page in the documentation explains the architecture of automatic data loading (i.e. the environment data that Orekit loads by itself under the hood when needed, like Earth Orientation Parameters, JPL ephemerides or gravity fields). You may browse around to other pages of documentation to see extended features like filtering. The application data page explains that the automatic loading mechanism from the data contexts can also be used for applications data, but that you can also load data by yourself (like what is done in the covariance tutorial for OPM data).
Thank you for your prompt responses. We greatly appreciate the ability to delve into discourse with you.
We have been going through the tutorials project in detail. The NumericalPropagation.java package was selected specifically because this was something that we felt would reflect Orekit’s depth and accuracy. Today we looked through the overview of CCSDS loading/writing features, along with architecture of automatic data loading and its mechanism.
Attached below is an example of an XML file we would like to implement – it represents the best estimated real-time trajectory and local sightings opportunities for the International Space Station (ISS) as generated by the Trajectory Operations and Planning (TOPO) flight controllers at Johnson Space Center. We are stuck as to where this file needs to be saved/called out in the files/code in order to swap places with the given data files provided for the tutorial to run. Going through the imported files within the NumericalPropagation.java package has not provided us with the information pertaining to where this data is found in the code – mostly due to our lack of experience with java and architectures as thorough as Orekit.
With regard to another package, ‘KalmanNumericalOrbitDetermination.java’, post-processing the outputted data led us to finding that DPx, DPy, and DPz take about 60 time steps to get within 50 m accuracy. Is this due to discrepancies in the data or could another function be added to improve the accuracy in less time steps? Or is this normal for orbit determination packages – such that the accuracy improves greatly over time? The attached file below contains our post processing of this package’s output thus far.
This is a classical OEM file (in a NDM packaging) in XML format. Orekit supports this file out of the box.
As in this file you already have the full orbit ephemeris, the numerical propagator would not be really useful and would not demonstrate anything. What could be instructive though would be to do some mix between either PropagatorConversion and numerical propagator or even better (but more difficult) between orbit determination and numerical propagator. The idea of the demonstration would be to use the ephemeris as reference data to be fed to a converter or an orbit determination process that would adjust a numerical propagator over the full range taking care of using the same perturbation that was used to generate the file and to check the residuals. Beware that if you do not use the same perturbations and same inertial frame in the adjusted model as in the original ephemeris then you will see differences. These differences will be the signature of the missing forces or misaligned frames. This is an interesting exercise, but may be a little too difficult to start with.
Anyway, if you want to load the NDM/OEM file, you can put it anywhere you want in a folder on your computer and use something along the following lines to load it and extract the ephemeris in the form of a bounded propagator:
File ndmFile = new File("/the/place/where/you/put/ISS.OEM_J2K_EPH.xml");
NdmParser parser = new ParserBuilder().buildNdmParser().;
NDM ndm = parser.parseMessage(new DataSource(ndmFile));
// here, we assume the NDM has one constituent that is an OEM
// of course it would be possible to loop over all constituents and handle each one differently
OEM oem = (OEM) ndm.getConstituents().get(0);
BoundedPropagator propagator = oem.getSatellites().get("1998-067-A").getPropagator();
For a Kalman filter, convergence highly depends on proper tuning of the noise matrices. The measurement noise is often easy to set up (just base it on the standard deviation of the measurement you use). The process noise matrix is a nightmare to set up and requires lots of experience and knowledge of the specific orbits you handle as well as its dynamics. If you are using it on ISS, beware that its drag force is complex to handle (and you also have to take care of the position of the ranging antenna wrt center of gravity, considering attitude).
Looking at your data, it also appears you have very large gaps, non-uniform coverage and one ground station only. There is a first small batch of 18 measurements over 36 minutes, then a 3h32 gap without any measurements, then 7 measurements covering 11 minutes, then another gap exceeding 4 hours.
This is hard for a Kalman filter that may well diverge during the long gaps without any measurements. Could you try using a batch least squares and perhaps add other measurements from one or two more ground stations?
We are very interested in implementing the suggestions you gave with mixing ‘PropagatorConversion’ and ‘NumericalPropagator’. We will be investigating this further tomorrow.
As far as loading the OEM, we managed to ensure that was done properly by running a separate java project – our issue is how to implement it within the tutorial in place of the provided data in the tutorial. Is this best done by importing the project that we created? Or is this best done by writing the code directly at the top of the tutorial script? Below is where we tried the ladder and could not get it to work. The image shows the errors that we were receiving.
With regard to the data gaps you mentioned based on our post processing of ‘KalmanNumericalOrbitDetermination.java’, this was directly from whatever data the tutorial reads in order to execute.
On another note, we are researching OEM files to input and are having trouble locating real flight data besides those from the ISS. Mainly, we are finding TLE files in XML format – as attached below. What tutorials would you recommend that would best demonstrate the TLE data in the attached files? Iridium Next.xml (77.9 KB)
We found PVT input data on a related forum discussion that another user had with you. Would you agree that this is the type of input data that we are looking for? W3B_skptest.txt (68.3 KB)
The company we are in collaboration with – Iridium – mainly operates communications constellations in LEO. One of their biggest problems is evenly scheduling data dumps. We noticed that Orekit has the possibility to schedule measurements as fixed step streams along with some customization aspect. Could this include the ability set an even time between these scheduling activities? How could this be demonstrated?
We greatly appreciate your continued time and support.
I made a typo in the code I proposed.
You should remove the dot between the closing parenthesis and the semicolumn at the end of line 81.
Sorry for that.
Real flight data is often difficult to get, especially accurate data. TLE are not accurate data and I
would not trust them for operations. The only advantage of TLE is that it is publicly available. One set of accurate real flight data is CDDIS.
The W3B data set corresponds to real data, but has one major drawback: it corresponds to a satellite that had a leak at launch and was ultimately driven back to burn in the atmosphere a few days later. The leak induced a hard to model force. In the tutorial, we used an extra parametric acceleration for this. It is clearly non-standard.
Orekit could help in scheduling ground to satellite access. There are several ways to do it. The first one is to simply use events detection with ElevationDetector to retrieve all possible visibility slots, and then to filter out these slots in a post-processing step. As for a large constellation and several ground stations the number of slots will be large, some dedicated algorithms should be set up for selection, typically using Constraint Programming. Neither Orekit nor Hipparchus provide anything related to contraint programming, but there are many other tools that do ; Orekit would only provide the data to triage. Another way would be to set up some a priori selection algorithm and use it on the fly during events detection, perhaps using EventEnablingPredicateFilter with a custom EnablingPredicate that would use some predefined slots for each satellite and hence arbitrarily reduce the number of visibilities.
With regard to the ISS OEM file, if we changed the drag coefficients, mass, and drag area to match that of an Iridium NEXT satellite; would that make sense to implement and be a viable representation of their smaller satellite (since the ISS is much larger)? This would also include changing the hard coded orbital elements in the test data.
We also had a few questions regarding the files below. Their data sets seem promising, and we were especially wondering where these may be implemented or already are used. SLRF2014_POS+VEL_2030.0_200428.snx (165.8 KB) current.al3 (6.4 KB)
As well as the GPS_Rinex304.n which is in the same folder as the current.al3 file above – (as new users we cannot attach more than two files per comment). Its file path is below.
“C:\Users\ajabr\orekit-tutorials-11.1\src\main\resources\tutorial-gnss\GPS_Rinex304.n”
We expect to come back with more technical questions in the coming days – as you have given us ample information to further investigate.
Thank you for all of the assistance you have given.
I just have few comments regarding the files you mentioned.
SLRF2014_POS+VEL_2030.0_200428.snx is a Sinex file. It contains station coordinates (i.e., position and velocity) for precise orbit determination. It doesn’t contain the coordinates of all the ground stations around the world, only the ones used for precise orbit determination. Indeed, for precise orbit determination, the station coordinates must have an accuracy at centimeter or even millimeter levels. Because to estimate a spacecraft coordinates at centimeter level, you need very accurate measurements and very accurate station coordinates. Therefore, the station coordinates available in Sinex files are the stations of the International GNSS Service (IGS) network for GNSS precise orbit determination or the ones of the International Laser Ranging Service (ILRS) network for laser ranging orbit determination.
current.al3 is a GPS almanac. It contains a representation of the orbit of GPS satellites at a given epoch. I want to reiterate that it is a representation and not the real orbit. To have the real orbit there is an almanac to coordinates conversion to perform. Orekit has this functionality represented by the GNSSPropagator class.
GPS_Rinex304.n is a navigation message. It also contains a representation of the orbit of GPS satellites at a given epoch. The main difference between almanac and navigation message is the accuracy. Indeed, navigation messages are more accurate because they contain additional parameters compared to the almanac. However, as the almanac, an almanac to coordinates conversion must be performed using the GNSSPropagator.
For an orbit determination purpose, almanac and navigation message can be used to initialize the initial guess of the orbit determination. But only for the orbit determination of GNSS satellites because the are related to this type of satellites.
