Orbit Determination with N-body attraction

1

Hello everyone!

I have embarked on a journey to perform Orbit Determination outside of the Earth’s Sphere of Influence.

In such a regime, we would need to consider the gravity of Earth, Moon, Sun, Jupiter, and an N number of bodies based on the use-case. An orbit in such a regime is generally non-Keplerian, non-planar, and not centered about a fixed barycenter (hinting to the inadecuacy of CR3BP limited realism for such a task in cislunar space, for example, to which @luc has eluded to here!.

The BLSEstimator I use requires a PropagatorBuilder. The underlying propagator that is built needs to have (inspired from the CR3BP tutorials):

  • numericalPropagator.setOrbitType(null), to clarify that the orbit is non-Keplerian
  • numericalPropagator.setIgnoreCentralAttraction(true), to clarify that there is no single central attraction point
  • numericalPropagator.addForceModel(...) with my choice of n-body accelerations from selected planetary bodies, similarly to @sebastien.herbiniere suggestion!

However, I do not have access to the first two methods from the NumericalPropagatorBuilder object. I noticed that the builder, inside the buildPropagator method, attempts to conditionally add a Newtonian attraction by itself from the input Orbit mu, if one such force is not present.

Adding the solar bodies as perturbation force models in an Earth-Centered initial orbit is probably not equivalent to what I would like to achieve, but yet again I am not sure now!

Question: What recommendations would you have to perform Orbit Determination within an n-body attraction environment, for a non-Keplerian orbit with known initial state guess in Cartesian coordinates (say in J2000?) ? I feel that if BatchLSEstimator had a NumericalPropagator argument instead of NumericalPropagatorBuilder, my problem would be solved, is that right or no? Alternatively, if the NumericalPropagatorBuilder could buildPropagator and keep a reference of the result in its instance as a member, I would also be able to reference it and use the setters on-the-fly (sounds too sketchy perhaps?).

Thank you!
Manny

P.S. Can I just say how happy I am for Orekit 12.0? :blush:

2

Hi @Manny

That’s an interesting challenge :blush:

You can find a discussion on this topic here: Orbit determination for interplanetary missions

To summarize, I think that Orekit needs some additional improvements to be able to perform orbit determination for interplanetary missions.
For orbit propagation, everything is OK. But for orbit determination we need further developments that are summarized in the topic above.

In addition, if remember well, I think the NewtonianAttraction is added automatically to the NumericalPropagatorBuilder. So we need to be able to avoid it for orbit determination of interplanetary missions.
An easy hack is to remove the acceleration of the Newtonian attraction by adding a ForceModel performimg the inverse acceleration. That’s ugly, but needed with the current status of the orbit determination.

I’m very interested on that topic!

Best regards,
Bryan

1 Like
3

Bryan, Thank you so much for such a speedy reply! :pray: @bcazabonne

Your linked topic is excellent and will proceed to dig into it now!
The reverse force model is simple, genius and out-of-the-box thinking! I now have fresh weekend homework!

I’ll report any progress I make with this hack below. Thank you once again!

1 Like