Poliastro: Relative motion, phasing, rendez-vous

[astrojuanlu]

🎯 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 🎉

[sammmlow]

Sounds like an interesting project! Phasing and rendezvous. Which part of the code do you think one would best start looking into?

[astrojuanlu]

Look at these beautiful LH-VH plots from https://digitalcommons.usu.edu/smallsat/2020/all2020/150/!

It was @sammmlow who recommended this article to me by the way... and I'm bummed to see I never replied to your comment! However, the answer is simple: there's nothing of this sort implemented in poliastro yet, so one should start from scratch. Perhaps there's something already in https://github.com/sammmlow/LEOGPS ? :)

[astrojuanlu]

More keywords: Hill-Clohessy-Wiltshire (HCW) equations. There are a couple of Python implementations on GitHub but they don't have a license and don't seem very well maintained, therefore I think it would be nice to have a "canonical" implementation in poliastro, even if it's in the core module and doesn't have direct application (in the same way some people, like AGI, are using poliastro just to import rv2coe and coe2rv).

[sammmlow]

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 :)

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

The propagation is based on the Clohessy-Wiltshire linearized equations, which was then improved by D'Amico's formulation in his paper:

_D'Amico, S., &; Montenbruck, O. (2006). Proximity operations of formation-flying spacecraft using an eccentricity/inclination vector separation. Journal of Guidance, Control, and Dynamics, 29(3), 554-563. doi:10.2514/1.15114_

Oh, and please assign me for this issue, I would love to work on this ;)

[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 :)