Allow the user to define an Orbit in any reference frame

🐞 Problem

As has been pointed out many times, it’s unclear which reference frame is poliastro using for Orbit objects, and the answer is that it’s implicitly assuming an inertial reference frame centered in the attractor (otherwise propagate wouldn’t work).

🎯 Goal

The use of reference frames in poliastro should be more explicit and configurable. Reference frame transformations are needed all the time, and now poliastro does not make things easy on this front.

💡 Possible solutions

See https://github.com/poliastro/poliastro/wiki/Orbits-and-reference-frames for further explanation and ideas.

📋 Steps to solve the problem

• Comment below about what you’ve started working on.
• Add, commit, push your changes
• Submit a pull request and add this in comments - Addresses #<put issue number here>
• Ask for a review in comments section of pull request
• Celebrate your contribution to this project 🎉

[astrojuanlu]

For example if orbital velocity of a satellite is equal to rotational velocity of the Earth(for simplicity, let attractor is Earth), then in ECEF reference frame orbit will be just a point(as per my current understanding). And there are a plenty of other similar cases.

That’s exactly the case of the geostationary orbits you introduced in #524 😉

There is no “orbit” in the sense that, in a non-inertial frame, it would not be a Keplerian orbit (a conic section), but stuff would revolve around the Earth no matter what reference frame we use to look at it.

What we want to achieve is to simplify the use case presented in https://github.com/poliastro/poliastro/issues/429, that is: make it a one-liner to create an Orbit object from data (most likely cartesian vectors) that is not in an inertial reference frame, or even a frame centered in the attractor we are looking at (think of an observer pointing a telescope or an antenna to some satellite).

The classical orbit elements are “just” geometric parameters, and therefore they should also be computed in an inertial frame, using proper conversion code.

[hrishikeshgoyal]

What we want to achieve is to simplify the use case presented in #429, that is: make it a one-liner to create an Orbit object from data (most likely cartesian vectors) that is not in an inertial reference frame, or even a frame centered in the attractor we are looking at (think of an observer pointing a telescope or an antenna to some satellite).

The way I can think of right now to solve this is that first transform the given parameters into an inertial reference frame centred at attractor and then create the orbit as usual and also always use that frame to plot the orbit(irrespective of what frame user has used).