A generalised ideal rocket equation

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
When I find a bit more time, I'll insert this into a two-variable root-finding algorithm.

Could we make a deal, that you prepare another version in such a way, that you don't care how long it takes to compute

However, for mill-G thrusts, the gravity model in the code may well need to include other gravitating bodies since the insertion burn may start outside or at the edge of Earth's SOI at 0.5 million km or more.

Please allow me a smile at the fact that after telling me that it's not as simple as fitting a numerical solution to the desired target you do it anyway, that we seem to reach agreement that brute-force numerics might actually feasible for planning and that it becomes apparent that for the multi-body gravitational problem all Kepler analytic cleverness disappears pretty quickly.

Well, any transit, really. It doesn't have to be a complete trajectory solver too, just a tool that can work with low acceleration for ejection and insertion, allowing to plan a low-thrust trajectory with some fiddling

It's a hard problem for analytical (aka 'clever') solution - I believe you pretty much have to compute the trajectory by fast-forwarding the equations of motion.

Which I think is fairly doable - but what do I know :lol: ?
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
We seem to reach agreement that brute-force numerics might actually feasible for planning and that it becomes apparent that for the multi-body gravitational problem all Kepler analytic cleverness disappears pretty quickly

Yes, and no. Not all Keplerian cleverness disappears with the introduction of perturbations. Out to the edge of the Earth's SOI at least, the Sun's gravitational contribution is effectively a small, tidal contribution.

The real problem is one of time-scale: the spacecraft will spend a long time far away from the Earth where the rate of change in the gravitational field is low; and a relatively short-time close to Earth where the rate of change in the gravitational field is high. In order for brute force numerical integration efforts to work efficiently across both regimes, some form of analytical transformation is required to 'regularise time' so that the integration procedure takes big time-steps when far away from the Earth and much smaller time-steps when it is close to the Earth.

My suggestion would be to transform the equations of motion using a Levi-Cevita style time regularisation. This resulting equations of motion would be essentially those of a harmonic oscillator - with a weak perturbation contribution from Solar tidal forces; and another weak thrust component from the spacecraft's engines.

Any thoughts, Thorsten?

---------- Post added at 11:54 PM ---------- Previous post was at 11:43 PM ----------

Enjo

Just to keep the ball rolling, I may have a go at converting my ham-fisted C code into a functioning Lua script. Whereas C/C++ MFD development probably lies outside my area of 'expertise', simple interfaces with Orbiter's system via a Lua script are not.

With any luck, this may nudge is a little closer towards a mutual understanding of how the orbit-insertion algorithm and code should work
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
At the moment, I can see no need for another version of the code. Whatever policy re first guesses you want to use, the algorithm works 'as is' and will already produce a refined value each time the MFD is refreshed (i.e., every time the algorithm is run.). You just need to choose a 'first guess' policy.

Sorry I can't be more helpful, but I'm a little baffled by your comment. We may well be talking at cross-purposes here.
Just a small misunderstanding then. In that case, I'm perfectly fine with what you wrote. Just take into account that I don't fully understand what you've done, hence my baffling comments.

Just to keep the ball rolling, I may have a go at converting my ham-fisted C code into a functioning Lua script. Whereas C/C++ MFD development probably lies outside my area of 'expertise', simple interfaces with Orbiter's system via a Lua script are not.

With any luck, this may nudge is a little closer towards a mutual understanding of how the orbit-insertion algorithm and code should work
The better you structure your code with regard to clean input/output separation, the easier it will be to incorporate into anything, be it Lua script or MFD.
I have no problem with working in parallel, especially since I need to spend time with my family for 2 weeks.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
Here's my take on the input / output separation. Let's use this version as current baseline. The project file there is for Code::Blocks IDE. Do you know it?

We slowly have to start thinking about the license of your code. Are you fine with LGPL / BSD? I need an Open Source - compatible license to include this code into BTC and TransX. Also, as far as parallel work goes, we might want to start a github project, if we end up overwriting each other's work.
 

Attachments

  • IdealRocket.zip
    9.5 KB · Views: 12

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Enjo

Thanks.

Sunday evening here in HK. I'll have a look at the code tomorrow and post comments.

wrt licenses: I'm fine with anything you are fine with.

---------- Post added 11-07-16 at 02:59 AM ---------- Previous post was 11-06-16 at 12:20 PM ----------

Here's my take on the input / output separation. Let's use this version as current baseline. The project file there is for Code::Blocks IDE. Do you know it?

No, not familiar with Code::Blocks IDE. But I've now downloaded it and installed it on my laptop. Although I'm not as familiar with C++ syntax as I am C, or even Objective C, the input/output separation looks fine to me. Whereas (for my convenience) I had orbit and vessel parameters set up as #define quantities, you have them passed to the various nested functions explicitly as function variables. All good.

I will load into Code::Blocks and run a few tests against my current Xcode program to see if your code produces the same results.

Also, as far as parallel work goes, we might want to start a github project, if we end up overwriting each other's work.

A GitHub project might be useful. I am aware that the Newton-Rapshon algorithm is a little 'brittle'. There are a couple of 'tweaks' to the N-R algorithm that I would like to make to make it somewhat more robust and that would probably imply that both of us working 'in parallel' on different bits of the code.

---------- Post added at 03:25 AM ---------- Previous post was at 02:59 AM ----------

Just run your Code::Blocks project. It produces the same output as my Xcode version. So, your translation seems to be working correctly.

The two crucial parameters to input are 'r' and 'tm'. The latter, 'tm' - the burn duration - should come directly from BTC; 'r' is sightly more problematic since it requires a transformation of BTC's 'time to start' of burn into 'r'. I've set out the principle of that transformation in an earlier post, but it may be helpful of I write some code to do this?

As for the other inputs, vessel and orbit parameters, my guess is that these should be readily available from within BTC.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
A GitHub project might be useful.
I will set it up by tomorrow morning.

The two crucial parameters to input are 'r' and 'tm'.(...) . I've set out the principle of that transformation in an earlier post, but it may be helpful of I write some code to do this?
It would be great. What you wrote serves as a good log, but a functioning code would spare a lot of experimentation. You could start writing even before I prepare the GitHub project, since I won't work on the code until then either.

As for the other inputs, vessel and orbit parameters, my guess is that these should be readily available from within BTC.
Yep.

---------- Post added at 05:32 PM ---------- Previous post was at 08:12 AM ----------

GitHub project done:
https://github.com/EnjoMitch/ideal-rocket-equation

Here's a simple tutorial:
http://rogerdudler.github.io/git-guide/
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Enjo

Thanks. No spare time at the moment to tinker with this. I may have some Thursday/Friday.

Regards
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
Keith, if let me learn your GitHub account name, I will add you to the Collaborators List, so that you can push changes directly.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Enjo, try 'kpgelling'. Thanks.
 
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Enjo - note that I've added a small piece of code that solves Kepler's equation to find 'r' from BTC's initial estimate of the time before periapsis that the orbit insertion burn should start. Let me know if you have questions.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
I had to clean up the repository, because I forgot to provide .gitignore earlier. You have to delete the current repository and clone again. Sorry.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
And here is a short video demonstrating the effectiveness of the maths set out earlier in this thread to determine the correct parameters for very low-thrust orbit insertion burns.


A Shuttle A, with modified low thrust (9000 N) main engines, in a high eccentricity lunar approach orbit executes one continuous 2.5 hour retrograde orbit insertion to achieve a 20 km x 20 km circular orbit.

(Orbiter crashes half way through Part 1. So, a forthcoming Part 2 will complete the orbit insertion burn.)
 
Last edited:

dgatsoulis

ele2png user
Joined
Dec 2, 2009
Messages
1,846
Reaction score
142
Points
78
Location
Sparta
And here is a short video demonstrating the effectiveness of the maths set out earlier in this thread...

Aaaaand now I'm addicted to low thrust transfers. Got to be even more creative with IMFD's map program.
Off to setup a Moon transfer with centi or even milli-g acceleration.

:cheers:

Seems to be workin nicely. Spiraling out for 13 orbits in a ~2.5 days burn.

Untitled-2_zps2kyutih8.gif
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,306
Reaction score
1,511
Points
203
Location
between the planets
(Orbiter crashes half way through the orbit insertion burn. So, a forthcoming Part 2 will complete the orbit insertion burn.)

Ha! The "Moving a dialog window with a mouse sent my vessel spinning out of controll"-bug! I already thought I was going crazy because I can't pin down the exact circumstances to reproduce it, but you captured it right on camera here! :)

Nice maths, can't wait to see a solver employing them! And also, pretty nice radio voice! :thumbup:
 
Top