Earth Observation and Constellation functionalities

Hello everyone,

I was just wondering what kind of features orekit has for mission design and operations of EO satellites and also what features there are for constellations mission analysis and operations.

Thank you.


This is a wide question!
Well, here are some random elements, a more complete list can be found here.

For mission analysis, you have the obvious basic set:

  • classical propagation you will find everywhere: analytical for speed, numerical for accuracy with all
    force models (gravity field to any degree and order, drag, solar radiation pressure, third body for any
    celestial body (i.e. not limited to Sun and Moon, you can add Venus or Jupiter or anything else for
    increased accuracy), solid tides, ocean tides, Earth albedo and infrared (i.e.rediffused radiation
    pressure), empirical forces, relativity, maneuvers (impulsive or continuous, including low thrust)
  • semi-analytical propagation with DSST, which combines the speed of analytical models with the
    accuracy of numerical models; this is useful for long term simulation, even past end of life of
    satellite, to assess reentry time if you want to comply with debris mitigation rules
  • events prediction (too many predefined to list, and also users can add their own mission-specific
    events, this includes on-board sensors fields of view with any shape)
  • covariance propagation
  • attitude modelisation
  • Taylor algebra (this is specially useful for doing Monte-Carlo analysis orders of magnitude faster
    than with regular propagation in a loop with randomized inputs)
  • generation of realistic simulated measurements for orbit determination (see below about OD)

For operations you can use the same set as above, perhaps with other sets of events more related
to operations (sensors dazzling, contacts with ground stations, fly over a region of interest…). Another feature important for operations is data exchange (orbit, attitude, tracking data) both importing and exporting them (Orekit 11 will by the way be one of the two reference implementation of the next CCSDS ODM standard which is not published yet and add OCM to the already supported OPM, OEM and OMM), we will also add Conjunction Data Messages support for debris mitigation. Of course reading and propagating TLE is supported since years, but we can also improve existing TLEs and do orbit determination directly in TLE (a paper was published a few weeks ago on this). A major feature for operation is Orbit Determination, which can be done using a lot of different measurements (Range, Doppler (one or two way), Azimut-Elevation, Right ascension-Declination, Turn-around, inter-satellite
range, position, position-velocity, inter-satelite phase, GNSS code, GNSS phase with ambiguity
resolution and wind-up. OD can be done with Batch Least Square or with Kalman filtering, and a sequential least square will be added soon (it is complete and is ongoing validation). OD can be used for calibrating maneuvers, and can be used in multi-satellite environment.

For constellations, the main features are the parallel propagation (i.e. propagation any number of orbits at the same time, with each propagator synchronized with the other ones, even if some are analytical propagators (for example for a reference satellite picked up among the constellation of formation-flying) and the other ones are numerical. This is used also in multi-satellite orbit determination, which is typically used if you have inter-satellite measurements and you need to adjusts several orbits in the same process.

One thing to note is that Orekit is used operationally since years by many space systems in the world and has been thoroughly validated: it is flight-proven. I remember a few years ago when someone at a conference presenting a new library explained that for validating it, they used Orekit as it was a reference. I was happy to learn that. The fact it is used and maintained by a community (agencies, operators, satellite manufacturers, academics and ground system integrators…) is also a key point: it increases reliability a lot as they all have different uses.

1 Like

Hello Luc,

Thank you very much for the very extensive answer. A couple of questions:

  • I am very interested in the “Earth albedo and infrared (i.e.rediffused radiation
    pressure)” part. Are we talking about radiometric budgets? Could you please point me at the functions to use this, in celestial body I can only find the PVCoordinates side of things.

How is parallel propagation performed, let’s say for one same propagator but many satellites? And is there any easy way of creating constellations, as in by following patterns rather than defining the satellites’ orbit sone by one?

Also, surely one of Orekit’s strength is the forum, thank you for making it so good :slight_smile:

Earth albedo and infrared correspond to the radiation pressure coming from the ground due to direct reflection of Sun light in the day time (albedo) and due to Earth thermal radiation (infrared). We use the classical Knock rediffused model. It is built from a PVCoordinatesProvider given by CelestialBodyFactory to know where the Sun is, and the model sums up the accelerations coming from Earth visible points with the current satellite, Earth, Sun geometry.

Parallel propagation is handled by PropagatorsParallelizer. You need to first build the set of individual propagators and give them to the parallelizer with a multisat step handler. Beware that the propagators will be run in a multithreaded environment (one thread for each propagator, the main thread remaining for the parallelizer), so you must make sure you don’t reuse some objects that store some internal state from one propagator from the other. Sharing frames, celestial bodies or gravity field providers and things like that is OK, but events handlers for example may not. I strongly recommend if you use numerical propagators to build each one from scratch with their own instance of integrator, their own instances of all force models. Some force models could be reused, but don’t rely on that, it is much safer and cleaner to just have everything separate. Look at the class javadoc, it explains how synchronization is achieved. The multisat step handle will see all satellites as it will be called with a list of interpolators, all valid for the current global step. There is one limitation with the parallelizer : you cannot set up directly multisatellite events (but you can enable events on each individual propagator).

I forgot about building a constellation.
There’s no helper for this, but it should be really simple, for example for Walker constellations. Something could be set up with a PropagatorBuilder and the Walker parameters, but we would need to check if force models can be shared or not, then the constellation builder would generate the list of propagators so they can be fed directly to the parallelizer. This would be a nice little project, perfectly suited for a first contribution if you want :wink:

Thank you very much Luc!