Closed jorgepiloto closed 3 years ago
After asking in the official Orekit forum, see this link, I was able to learn how to use the proper frame to define the local velocity impulses. However, the current Orekit based API does not match results predicted by GMAT while poliastro does.
Here is the GMAT2020a script which serves as expected results source:
https://gist.github.com/jorgepiloto/9ba39b782f0623537511d238c6c04463
The orbit starts near perigee but still needs to reach this positions. The reason behind this is just to make sure that triggers do not introduce additional undesired behaviour. For example, if an orbit in GMAT starts at periapsis (let us say you do not now initial position) and you force it to propagate to periapsis (so you can be sure where it is going to be before starting the maneuver), it will introduce +1 revolution, that is tof = tof_maneuver + 1 period.
Same reason applies for the extra 1 hour propagation. GMAT does not supply final orbit elements until you have crossed orbit's apoapsis.
I am suspecting now about the fact that final orbit is circular. This can affect Orekit propagators, see this lines from the ApsideDetector event detector:
Beware that apside detection will fail for almost circular orbits. If for example an apside detector is used to trigger an ImpulseManeuver and the maneuver change the orbit shape to circular, then the detector may completely fail just after the maneuver has been performed!
I decided to use an EventLogger()
in order to know at which epoch were the at_periapsis
and at_apoapsis
events being detected. Obtained results show those are not being executed at the right epochs. In addition, the introduction of an EventLogger()
seems to affect final results by several orders of magnitude. This is becoming really weird...
In the latest push, I added two new files: test_maneuvers.py
and test_raw_hohmann.py
. The reason behind this is as follows: although the same code flow is being run through the usage of custom OrekitManeuver
and OrekitOrbit
classes, final result is not the same as the one coming from a raw usage of the Orekit
wrapper. I've checked line by line, even forcing again vectors to be in the orbit frame and still did not found why final result does not approach the one in test_raw_hohmann.py
.
After discussing with @astrojuanlu, we decided to change the current validation approach, that is, without making use of a custom API relying on Orekit.
Therefore, I am closing this as in the next hours a new PR will be opened to propose a reformat on all mother code. I already made some changes locally and must say that everything got super clean and simple. In addition, code seems to be more stable as no random errors and no-sense results were raised.
Great to know @jorgepiloto , thanks for the update and all the detailed discussion and links! Looking forward to reviewing that PR
This PR solves for gh-10. By adding a
apply_maneuver
method to the actualOrekitOrbit
class (same API as poliastro), it is possible to apply impulsive maneuvers to any instance of the object. However, some problems were found when implementing this:KeplerianPropagator
hangs and raises an error. This has nothing to do with the actual implementation but a really weird behavior discovered while working on the issue.TNW
basis, which stands for "tangential" as this frame is aligned with local velocity. Therefore, impulses are always in the direction of the spacecraft velocity.I guess it can be something related with frames, since vectors were introduced in the
TNW
. Hopefully, studying those will be helpful not only for this issue but also when validating planetary reference frames.