Relative motion, phasing, rendez-vous

🎯 Goal

💡 Possible solutions

📋 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]

I am back three years late on this topic, so I must apologise, and hope it is not to late to make a contribution in this area 😃

Sometimes the pace of open source is slow 😃 But I’m so happy that you still want to contribute!

I have created a rough sample of a basic relative orbit object class, do you think this structure is OK?

Now that we have our contrib/ directory, what do you think about adding there relative_eccentricity_vector(...) and relative_inclination_vector first, before we go any further? This way we can also identify which parts could be moved to poliastro.core at the same time we review it. I am not so sure what sampling would do, but I’m sure I will understand it better when I see the other two 😃 And also, the plot function will probably be useful! But again, let’s go step by step so the review is palatable 😄

[sammmlow]

I’m thinking if we might like to see a core relative_orbit class, that can be called as a separate module under poliastro.twobody? What do you think Juan? I could do up the docs for it too 😃