First steps toward a flight plan! | Orbits and burns | Forum

Post edited 3:30 pm – November 24, 2009 by Luke Maurits

Today I wrote an extremely simple first approximation to the sort of software we will eventually need to use to create our flight plan.  It simulates the effects of a Trans Lunar Injection (TLI) burn from a circular Earth parking orbit.  One can specify the delta-V of the burn, its direction and the relative position of the CSM and the moon at the time of the burn.  The burn is modelled as an instantaneous delta-V and all motion after it is purely under the influence of gravity.  For now the program just produces text files containing time series of coordinates.  I have been using gnuplot to visualise the results for the time being.

The image below shows the results for a variety of delta-V values, ranging from 0 (in which case the CSM remains in its circular parking orbit, the red case) through 1000, 2000, 3000 and 4000 m/s.  The final burn puts the CSM past escape velocity, hence the long, nearly straight aqua line which flies off into the distance.  All the lesser burns just put the CSM into increasingly eccentric orbits around the Earth, which are the green, blue and purple ellipses.

The image below is zoomed out a lot to show interactions of the CSM's trajectory with the moon.  It's not very clear, sorry, I put these together in a hurry.  The Earth is located at the bottom right of the plot (at (0,0) on the axes).  The red arc is a segment of the moon's orbit around the Earth.  All the other lines are CSM trajectories.  All the trajectories have exactly the same delta-V, which is why they are blurred together into a yucky yellow-green line for most of the trip.  But the trajectories happen at slightly different times, so that they pass nearer or further to the moon.  You can see the deflection of the trajectories when they get near the red line, which is the moon's path.  The trajectories are being deflected rather sharply by the moon's gravity – I was hoping to find a free return trajectory which would swing the CSM back around headed toward Earth, but couldn't get it to work.  I think the CSM is travelling too fast to achieve free return in these simulations, I will have to experiment more later.  A quick note on the length of the various trajectories.  They all terminate an equal amount of time after launch, so the fact that the light blue line extends so very far after its deflection means that the CSM in this case has picked up an awful lot of speed during its gravitational sling shot!

[Image Can Not Be Found]

The image below shows the same data as the last image, but it is zoomed in on the interesting part, where the CSM's trajectory interacts with the moon's gravity.  Note the really interesting loopy structure of the light blue trajectory!

That's all for now, these really are the absolute earliest experiments with a very rough play toy.  Nevertheless, it seems to be acting sensibly enough and I am optimistic about being able to extend it to be more useful.

Here's a list of things that will need to be tweaked for future versions, which will increase accuracy a lot:

• Currently the equations of motion are solved using Euler's method, which is the most blindingly simple algorithm for numerical solution of DEs there is, and which doesn't have great accuracy.  A later version should use something like the 4th order Runge Kutta method for improved accuracy.  This really won't be all that hard to implement.
• Real life injection burns will not be instantaneous.  They extend over a few minutes, and the acceleration increases slightly over that time as fuel mass is lost.  This should not be hard to model more accurately.
• The moon's orbit is modelled as a perfectly circular orbit around the Earth, with a radius that is the mean of the apogee and perigee of the moon's true elliptical orbit.  A later version should use the moon's actual orbit.  This shouldn't be too hard, either, orbital parameters for the moon will be easy to find.
• Gravity from the sun is currently completely ignored – only the Earth and the moon have any effect on the CSM's trajectory.  This may be a little bit of work to add.
• Solar radiation pressure is ignored completely.  My intuition is that this will not make a noticeable difference, but if it is easy enough to add, it will not hurt.
• There is no collision detection, the Earth and moon are both modelled as point masses.  I'm not unconvinced the super high speed light blue orbit doesn't actually involve getting closer to the moon than its physical radius would allow.   This would be easy to check, though.
• Modelling the Earth and moon as point masses ignores the fact that they are not perfect spheres, which has a subtle influence on their gravitational fields.  I don't know enough of the relevant theory to estimate either how big of a difference this is likely to make or how hard it will be to improve.
• This doesn't really affect the physical accuracy of the current simulations, but is more about accurately simulating something closer to what will actually happen: we should not assume that the CSM begins in a perfectly circular parking orbit.  Rather, we should be able to specify orbital parameters which we can determine from ground observations.

The other big short coming is that exploring the space of possible orbits now is literally a matter of manually guessing good values for all the parameters, looking at the plots, changing them, etc. until you get something close to what you want.  A better solution would be to determine some rough heuristics that can automatically ballpark, e.g. the relative position of the CSM and the moon at TLI burn time on the basis of the specified delta-V or vice versa, and then use quickly test a range of parameters within the neighbourhood of that ballpark to find some values that fit the desired criteria.

I will continue work on this software over the next few days and keep you all posted.  Once I have some code that is a little bit neater than what I am using now I will start putting copies of it in our DropBox so other people can have a look and contribute.  I think developing this program to the point that it enables really smooth and accurate flight planning will be a lot of fun and a great achievement for us!  We should endeavour to make sure it is adaptable from CLLARE to later missions.  Basically we should end up with something like a completely open source version of the Orbiter software that it was suggested we use for basic planning.

Feedback on anything and everything in this post is welcome!

I have updated the code used to produce those previous plots somewhat.  It now features:

• RK4 integration instead of Euler's method
• Moon follows a Keplerian orbit instead of a perfect circle
• Collision detection

I wanted to put the code in our CSTART Dropbox account but realised I don't know the info@cstart.org account password.  If someone could email it to me, that would be great.  For now, I'm hosting the code myself here.  I've put this version in the public domain since we haven't had a discussion yet about what the official CSTART license will be.

I've really enjoyed working on this.  I feel like there is a fairly natural evolutionary path for this program, from a simple lunar TLI simulator to a generic mission planning program that can compute trajectories to anywhere in the solar system.  Of course our first use for it will be purely lunar in nature but it should not be too hard to avoid artificially limiting it to the moon as we develop.  We can simply have it load orbital elements for a series of bodies in a list, and just set the list to only contain the moon for now.  In addition to plotting trajectories it could take care of things like predicting periods of radio blackout (which is just simple geometry – does a straight line from the craft to the Earth intersect any of the bodies), etc.

I would be excited to play a fairly key role in developing this software but don't want to get too carried away before there is some discussion to figure out, e.g.

• What the program should be called!
• What the most useful things to put in the program's scope would be,
• What language it should be written in,
• Which GUI library it should use  (which will depend on the above),
• What license it should be under, etc.

Questions, comments?

It's written in Python, but I realise that the "real version" of our mission planning software will need to be written in a language that is decided by a group.

If it makes it easier to collaborate with you, I also know C and Java, but I feel like switching to those languages would probably just slow progress down tremendously.

I'm glad you are interested in helping, I'm quite keen to see a good discussion of where this program may go, answering some of the questions I sketched above.